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本 章 介绍 开始 使 用 Git 前 的 相关 知识 。 我 们 会 先 了 解 一 些 版 本 控制 工具 的 历史 背景 ， 然 后 试 着 在 你 的 系统 
上 把 cit 跑 起 来 ， 直 到 最 后 配置 好 ， 可 以 开始 正常 的 开发 工作 。 读 完 本 章 ， 你 就 会 理解 为 什么 Git 会 如 此 流 
行 ， 为 什么 你 真 的 需要 使 用 它 。 
























































































































































1.1 关于 版 本 控制 










































































什么 是 版 本 控制 ? 我 真 的 需要 吗 ? 版 本 控制 是 一 种 记录 若干 文件 内 容 变化 ， 以 便 将 来 查阅 特定 版 本 修订 情况 
的 系统 。 在 本 书 所 展示 的 例子 中 ， 我 们 仅 对 保存 着 软件 源 代码 的 文本 文件 作 版 本 控制 管理 ， 而 实际 上 ， 你 可 上 
对 任何 类 型 的 文件 进行 版 本 控制 。 
如 果 你 是 位 图 形 或 网 页 设计 师 ， 可 能 会 需要 保存 某 一 幅 图 片 或 页 面 布局 文件 的 所 有 修订 版 本 。 采 用 版 本 控制 
系统 (VCS) 是 个 明知 的 选择 。 有 了 它 你 就 可 以 将 某 个 文件 回 漳 到 之 前 的 状态 ， 长 至 将 整个 项 目 都 回 退 到 过 去 
某 个 时 间 点 的 状态 。 你 可 以 比较 文件 的 变化 细节 ， 查 出 是 谁 最 后 修改 了 什么 地 方 从 而 造成 某 些 怪异 问题 ， 又 是 
谁 在 何 时 报告 了 某 个 功能 缺陷 ， 等 等 。 使 用 版 本 控制 系统 通常 还 意味 着 ， 就 算 你 胡来 搞 砸 了 整个 项 目 ， 把 文件 
改 的 改 ， 删 的 删 ， 你 也 可 以 轻松 恢复 到 原先 的 样子 。 而 由 此 额外 增加 的 工作 量 却 微乎其微 。 
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1.1.1 本 地 版 本 控制 系统 


许多 人 习惯 用 复制 整个 项 目 目录 的 方式 来 保存 不 同 的 版 本 ， 或 许 还 会 改名 加 上 备份 时 间 以 示 区 别 。 这 么 做 唯 

一 的 好 处 就 是 简单 ， 不 过 坏处 却 不 少 : 有 时 候 会 混 消 所 在 的 工作 目录 ， 和 弄 错 了 文件 委 了 数据 就 没 了 后 退 的 路 。 
为 了 解决 这 个 问题 ， 人 们 很 久 以 前 就 开发 了 许多 种 本 地 版 本 控制 系统 ， 大 多 都 是 采用 某 种 简单 的 数据 库 来 记 
录 文 件 的 历次 更 新 差异 GLA 1.1) 。 
中 最 流行 的 一 种 叫做 rcs， 现 今 许多 计算 机 系统 上 都 还 看 得 到 它 的 踪影 。 甚 至 在 流行 的 Mac OS X 系统 
安装 了 开发 者 工具 包 之 后 ， 也 可 以 使 用 res 命令 。 它 的 工作 原理 基本 上 就 是 保存 并 管理 文件 补丁 (patch) o 
文件 补丁 是 一 种 特定 格式 的 文本 文件 ， 记 录 着 对 应 文件 修订 前 后 的 内 容 变 化 。 所 以 ， 根 据 每 次 修订 后 的 补 
T, res 可 以 通过 不 断 打 补丁 ， 计 算出 各 个 版 本 的 文件 内 容 。 





















































































































































































































































































































































































































































1.1.2 集中 化 的 版 本 控制 系统 


接 下 来 人 们 又 下 到 一 个 问题， 如 何 让 在 不 同系 统 上 的 开发 者 协同 工作 ? 于 是 ， 集 中 化 的 版 本 控制 系统 
Centralized Version Control Systems, PR CVCS ) 应 运 而 生 。 这 类 系统 ， 诸 如 CVS, Subversion È 
Perforce 等 ， 都 有 一 个 单一 的 集中 管理 的 服务 器 ， 保 存 所 有 文件 的 修订 版 本 ， 而 协同 工作 的 人 们 都 通过 
户 端 连 到 这 人 台 服 务 器 ， 取 出 最 新 的 文件 或 者 提交 更 新 。 多 年 以 来 ， 这 已 成 为 版 本 控制 系统 的 标准 做 法 ( 见 
1.2) » 
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这 种 做 法 带 来 了 许多 好 处 ， 特 别 是 相 较 于 老式 的 本 地 VCs 来 说 。 现 在 ， 每 个 人 都 可 以 一 定 程 度 上 看 到 项 目 
! 的 其 他 人 正在 做 些 什么 。 而 管理 员 也 可 以 轻松 掌控 每 个 开发 者 的 权限 ， 并 且 管 理 一 个 CVCS 要 远 比 在 各 个 客 
户 端 上 维护 本 地 数据 库 轻 松 容易 得 多 。 
o 这 么 做 最 显而易见 的 缺点 是 中 央 服 务 器 的 单 点 故障 。 若 是 宕 
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图 1.1: 本 地 版 本 控制 系统 
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Computer B 
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图 1.2: 集中 化 的 版 本 控制 系统 





















































有 好 有 坏 
时 内 ， 谁 都 无 法 提交 更 新 ， 也 就 无 法 协同 工作 。 如 果 中 央 服 务 器 的 磁 强 发 生 故 障 
不 够 及 时 的 话 ， 还 会 有 丢失 数 据 的 风险 。 最 坏 的 情况 是 彻底 丢失 整个 项 目的 所 有 
出 来 的 某 些 快照 数据 除外 ， 但 这 样 的 话 依然 是 个 问题 ， 你 不 能 保证 所 有 的 数据 都 已 经 有 人 提取 出 来 。 
控制 系统 也 存在 类 似 问 题 ， 只 要 整个 项 目的 历史 记录 被 保存 在 单一 位 置 ， 就 有 丢失 所 有 历史 更 新 
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1.1.3 分 布 式 版 本 控制 系统 

















于 是 分 布 式 
诸如 Git, Me 


仓库 完整 地 镜像 下 来 。 这 么 一 来 ， 任 何 一 处 协同 工作 用 的 服务 器 发 生 故 障 ， 事 后 都 可 以 月 
本 地 仓库 恢复 。 因 为 每 一 次 的 提取 操作 ， 实 际 上 都 是 一 次 对 代码 仓库 的 完整 备份 ( 见 
更 进一步 ， 许 多 这 类 系统 都 可 以 指定 和 若 1 











1， 分 别 和 不 





版 本 控制 系统 ( Distributed Version Control System, 简称 DVCS ) 面世 了 。 在 这 类 系统 中 ， 
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昌 没 做 过 














机 一 小 时 ， 那 么 在 这 一 小 
份 或 者 备份 得 
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息 的 风险 。 








Bazaar 还 有 Darcs 等 ， 客 户 端 并 不 只 提取 最 新 版 本 的 文件 快照 ， 而 是 把 原始 的 代码 
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是 无 法 实现 的 。 











图 1.3) 。 





任何 一 个 镜像 出 来 的 








不 同 的 远 端 代码 仓库 进行 交互 。 籍 此 ， 你 就 可 以 在 同一 个 项 
同 工 作 小 组 的 人 相互 协作 。 你 可 以 根据 需要 设 定 不 同 的 协作 流程 ， 比 方 说 层次 模型 式 的 工作 流 ， 
! 式 系统 
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Version Database 




















































































































































































































Computer B 


Version Database 











1.2% Git 的 历史 













































































































































































图 1.9: 分 布 式 版 本 控制 系统 
1.2 Git 的 历史 

同 生活 中 的 许多 伟大 事件 一 样 ，Git 诞生 于 一 个 极 富 纷争 大 举 创新 的 年 代 。Linux 内 核 开源 项 目 有 着 为 数 
众 广 的 参与 者 。 绝 大 多 数 的 Linux 内 核 维护 工作 都 花 在 了 提交 补丁 和 保存 归档 的 繁琐 事务 上 (1991 一 2002 年 
间 ) 。 到 2002 年 ， 整 个 项 目 组 开始 启用 分 布 式 版 本 控制 系统 BitKeeper 来 管理 和 维护 代码 。 

到 2005 年 的 时 候 ， 开 发 Bitkeeper 的 商业 公司 同 Linux 内 核 开源 社区 的 合作 关系 结束 ， 他 们 收回 了 免费 
使 用 BitKeeper 的 权力 。 这 就 迫使 Linux 开源 社区 (特别 是 Linux 的 缔造 者 Linus Torvalds ) 不 得 不 吸 
取 教 训 ， 只 有 开发 一 套 属于 自己 的 版 本 控制 系统 才 不 至 于 重 蹈 履 略 。 他 们 对 新 的 系统 订 了 若干 目标 : 

- XE 

- 简单 的 设计 

.对 非 线性 开发 模式 的 强力 支持 (允许 上 千 个 并 行 开发 的 分 支 ) 

e 完全 分 布 式 

- 有 能 力 高 效 管理 类 似 Linux 内 核 一 样 的 超大 规模 项 目 (速度 和 数据 量 ) 

自 诞生 于 2005 年 以 来 ，Git 日 号 成 熟 完善 ， 在 高 度 易 用 的 同时 ， 仍 然 保 留 着 初期 设 定 的 目标 。 它 的 速度 飞 
快 ， 极 其 适合 管理 大 项 目 ， 它 还 有 着 令 人 难以 置信 的 非 线性 分 支管 理 系统 ( 见 第 三 章 ) ， 可 以 应 付 各 种 复杂 的 
项 目 开发 需求 。 





1.3 Git 基础 要 点 


那么 ， 

















简单 地 说 ，Git 究竟 是 怎样 的 一 个 系 


























想 和 基本 的 工作 原理 ， 
和 其 他 的 版 本 控 








起 来 就 会 入 





sad 


制 系统 诸如 Subversion 和 Perforce 








统 呢 ? iE 


LPT, WIAR? E 





意 ， 接 下 来 的 内 容 非 常 重要 ， 
开始 学 习 Git 的 时 候 ， 请 




















若是 理解 了 cit 的 思 
不 要 尝试 把 各 种 概念 











等 相 比拟 ， 

















否则 容易 混 消 每 个 操作 的 实际 意 





X Git 在 
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保存 和 处 理 各 种 信息 的 时 候 ， 虽 然 操 作 起 来 的 命令 形式 非常 相近 ， 但 它 与 其 他 版 本 控制 系统 的 做 法 颇 为 不 同 。 
理解 这 些 差异 将 有 助 于 你 准确 地 使 用 Git 提供 的 各 种 工具 。 


























Hr 

















1.3.1 直接 快照 ， 而 非 比 较 差 异 



























































Git 和 其 他 版 本 控制 系统 的 主要 差别 在 于 ，Git 只 关心 文件 数据 的 整体 是 否 发 生变 化 ， 而 大 多 数 其 他 系统 则 
只 关心 文件 内 容 的 具体 差异 。 这 类 系统 (CVS，Subversion，Perforce，Bazaar 等 等 ) 每 次 记录 有 哪些 文件 作 
了 更 新 ， 以 及 都 更 新 了 哪些 行 的 什么 内 容 ， 请 看 图 1.4。 












































——————— Checkins over time 一 
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ea ————Ó*3—02 
eo a —— —069 


图 1.4: 其 他 系统 在 每 个 版 本 中 记录 着 各 个 文件 的 具体 差异 














Git 并 不 保存 这 些 前 后 变化 的 差异 数据 。 实 际 上 ，Git 更 像 是 把 变化 的 文件 作 快照 后 ， 记 录 在 一 个 微型 的 文 
件 系统 中 。 每 次 提交 更 新 时 ， 它 会 纵览 一 遍 所 有 文件 的 指纹 信息 并 对 文件 作 一 快照 ， 然 后 保存 一 个 指向 这 次 快 
照 的 索引 。 为 提高 性 能 ， 若 文件 没有 变化 ，Git 不 会 再 次 保存 ， 而 只 对 上 次 保存 的 快照 作 一 连接 。Git 的 工作 
方式 就 像 图 1.5 所 示 。 

































































Checkins over time 一 





图 1.5: Git 保存 每 次 更 新 时 的 文件 快照 




















这 是 Git 同 其 他 系统 的 重要 区 别 。 它 完全 显 履 了 传统 版 本 控制 的 套路 ， 并 对 各 个 环 市 的 实现 方式 作 了 新 的 


设计 。Git 更 像 是 个 小 型 的 文件 系统 ， 但 它 同时 还 提供 了 许多 以 此 为 基础 的 超 强 工具 ， 而 不 只 是 一 个 简单 的 
vcs。 稍 后 在 第 三 章 讨 论 Git 分 支管 理 的 时 候 ， 我 们 会 再 看 看 这 样 的 设计 究竟 会 带 来 哪些 好 处 。 












































































































































1.3.2 近乎 所 有 操作 都 可 本 地 执行 


在 Git 中 的 绝 大 多 数 操作 都 只 需要 访问 本 地 文件 和 资源 ， 不 用 连 网 。 但 如 果 用 CVCS 的 话 ， 差 不 多 所 有 操 
作 都 需要 连接 网 络 。 因 为 Git 在 本 地 磁 副 上 就 保存 着 所 有 有 关 当 前 项 目的 历史 更 新 ， 所 以 处 理 起 来 速度 飞 
快 o 
举 个 例子 ， 如 果 要 浏览 项 目的 历史 更 新 摘要 ，Git 不 用 跑 到 外 面 的 服务 器 上 去 取 数 据 回 来 ， 而 直接 从 本 地 数 
据 库 读 取 后 展示 给 你 看 。 所 以 任何 时 候 你 都 可 以 马上 翻阅 ， 无 需 等 待 。 如 果 想 要 看 当前 版 本 的 文件 和 一 个 月 前 
的 版 本 之 间 有 何 差异 ，Git 会 取出 一 个 月 前 的 快照 和 当前 文件 作 一 次 差异 运算 ， 而 不 用 请 求 远程 服务 器 来 做 这 
牛 事 ， 或 是 把 老 版 本 的 文件 拉 到 本 地 来 作 比 较 。 
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用 CVCS 的 话 ， 没 有 网 络 或 者 断 帮 






































































































































E n 




















EF oh lE " 




















































































































上 去 好 像 这 些 都 不 是 














平 不 可 能 ， 






























































后 ， 你 就 会 惊喜 地 发 现 ， 这 其 实 




















时 刻 保 持 数 据 完 整 性 


在 保存 到 Git 之 前 ， 所 有 
天 说 ， 不 可 能 在 你 修改 了 
在 整体 架构 的 最 底 



































行内 容 的 校 验 和 (checksum) 计算 ， 
l , Git 一 无 所 知 。 这 项 特 全 
时 变 得 不 完整 ， 或 者 磁 强 损坏 导致 文人 






















































































1.3 节 Git 基础 要 点 

















用 cit 的 话 ， 
程 的 镜像 仓库 。 同 样 ， 在 
抑或 非常 厂 烦 。 
F 权 限 改 为 可 写 之 后 是 可 以 编辑 文件 
;如 果 是 Subversion 或 CVS, BRATJE 












































就 算 你 在 飞机 或 者 火车 上 ， 
家 的 路 上 ， 不 用 


的 > IN 


















































什么 大 问题 ， 但 在 实际 体验 过 之 


























J 年 










































































据 的 校 验 和 ， 通 过 对 文 但 
出 字符 (0-9 及 af) £ 





















































， 看 起 


























24b9da6552252987aa493b52 


cit 的 工作 完全 依赖 了 的 哈 硕 人 

















串 ， 所 以 你 会 经 常 看 到 这 检 
来 作 索引 的 ， 而 不 是 靠 文件 名 。 
























































1.3.4 多 数 操作 仅 添加 数据 











it HORT, E 
EXE BOR 














录 的 结构 计算 出 一 个 SHA-1 哈 希 人 
RB Re: 




































































作 大 多 仅仅 是 把 数据 添加 到 数据 局 




















不 可 逆 上 
































标 y 3 





， 作 为 


。 实际 上 ， 所 有 保存 在 Git 数据 库 








操作 ， 比 如 删除 数 ] 


可 退 或 

















lai 
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这 种 高 可 靠 性 令 我 们 

































































Git 内 部 究竟 是 如 何 保存 和 


























再 怎样 也 不 会 弄 丢 数据 。 



































要 讲 的 概念 非常 
， 已 修改 (modified) 和 已 
个 文件 ， 但 还 没有 提交 保存 ; 



























































































































































Xi: Git WASH 




















































































































， 实 际 拷贝 的 就 是 这 个 目 







































































E 何 一 个 文件 ， 在 Git 内 都 
o 已 提交 表示 该 文件 
暂 存 表示 把 已 修改 





























能 丢失 或 者 混 消 一 些 修改 的 内 容 ， 但 在 Git 
在 养 成 了 定期 推送 至 其 
试验 性 的 尝试 好 了 ， 
"Euge" Marmi - 


























已 经 被 安全 地 保存 在 本 : 











已 提交 


EET 




















F 放 在 下 次 提交 时 要 保存 











vej 











SRL Re 




















局 和 对 象 数据 库 的 地 方 。i 






































作 的 叫做 工作 目录 。 这 些 文件 实际 - 

































































对 这 些 文件 i 


















































F, 一般 都 放 在 git 











目录 中 。 有 时 候 人 们 会 






























































区 








上 都 是 从 git 


这 个 文件 叫做 索引 文 
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Local Operations 





图 1.6: 工作 目录 ， 暂 存 区 域 和 git 目录 




















1. 在 工作 目录 中 修改 某 些 文件 。 
2. 对 这 些 修改 了 的 文件 作 快照 ， 并 保存 到 暂 存 区 域 。 
3. 提交 更 新 ， 将 保存 在 暂 存 区 域 的 文件 快照 转 储 到 sit 目录 中 。 


所 以 ， 我 们 可 以 从 文件 所 处 的 位 置 来 判断 状态 ， 如 果 是 sit 目录 中 保存 着 的 特定 版 本 文件 ， 就 属于 已 提交 状 
态 ， 如 果 作 了 修改 并 已 放 入 暂 存 区 域 ， 就 属于 已 暂 存 状态 ， 如 果 自 上 次 取出 后 ， 作 了 修改 但 还 没有 放 到 暂 存 区 
域 ， 就 是 已 修改 状态 。 到 第 二 章 的 时 候 ， 我 们 会 进一步 了 解 个 中 细节 ， 并 学 会 如 何 善 用 这 些 状态 ， 以 及 如 何 跳 
过 暂 存 环节 。 
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1.4 安装 Git 

















是 时 候 动 动手 了 ， 不 过 在 此 之 前 得 先 安装 好 Git。 有 许多 安装 方式 ， 概 括 起 来 主要 有 两 种 ， 一 种 是 通过 编译 
源 代码 来 安装 ， 男 一 种 是 使 用 为 特定 平台 预 编 译 好 的 安装 包 。 



























































1.4.1 从 源 代 码 安 装 














若是 条 件 允 许 ， 从 源 代码 安装 有 很 多 好 人 处， 至 少 可 以 安装 最 新 的 版 本 。Git 的 每 个 版 本 都 在 不 断 尝试 改进 用 
户 体 验 ， 所 以 能 通过 源 代码 自己 编译 安装 最 新 版 本 就 再 好 不 过 了 。 有 些 Linux 版 本 自 带 的 安装 包 更 新 起 来 
不 及 时 ， 所 以 除非 你 在 用 最 新 的 distro 或 者 backports， 那 么 从 源 代码 安装 其 实 该 算是 最 佳 选 择 。 

Git 的 工作 需要 调用 curl, zlib, openssl, expat, libiconv 等 库 的 代码 ， 所 以 需要 先 安装 这 些 依赖 工 
具 。 在 有 yum 的 系统 上 (比如 Fedora) 或 者 有 apt-get 的 系统 上 (比如 Debian 体系 的 ) ， 可 以 用 下 面 的 


BA Fike 
STR: 




















































































































































































































$ yum install curl-devel expat-devel gettext-devel \ 


openssl-devel zlib-devel 


$ apt-get install curl-devel expat-devel gettext-devel \ 


openssl-devel zlib-devel 
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之 后 ， 从 下 面 的 Git 官方 站 点 下 载 最 新 版 本 源 代码 : 
http://git-scm.com/download 


然后 编译 并 安装 : 


TON H 




































































$ tar -zxf git-1.6.0.5.tar.gz 
3 @@ pala 6.0.5 
$ make prefix=/usr/local all 


$ sudo make prefix=/usr/local install 







































































现在 已 经 可 以 用 sit RET, 用 git 把 Git 项 目 仓库 克隆 到 本 地 ， 以 便 日 后 随时 更 新 : 











$ git clone git://git.kernel.org/pub/scm/git/git.git 


1.4.2 在 Linux 上 安装 






















































































如 果 要 在 Linux 上 安装 预 编译 好 的 Git 二 进 制 安 装 包 ， 可 以 直接 用 系统 提供 的 包 管理 工具 。 在 Fedora 上 


yum 安装 : 















































$ yum install git-core 


在 Ubuntu 这 类 Debian 体系 的 系统 上 ， 可 以 用 














apt-get 安装 : 








$ apt-get instal git-core 


1.4.3 在 Mac 上 安装 



























































在 Mac 上 安装 Git 有 两 种 方式 。 最 容易 的 当 属 使 用 图 形 化 的 Git 安装 工具 ， 界 面 如 图 1.7， 下 载 地 址 在 : 
http://code.google.com/p/git-osx-installer 
另 一 种 是 通过 MacPorts (http://www.macports.org) 安装 。 如 果 已 经 装 好 了 MacPorts， 用 下 面 的 命令 安 


E Git: 














































































































$ sudo port install git-core +svn *doc *bash completion +gitweb 






































这 种 方式 就 不 需要 再 自己 安装 依赖 库 了 ，Macports 会 帮 你 搞定 这 些 麻烦 事 。 一 般 上 面 列 出 的 安装 选项 已 经 
够 用 ， 要 是 你 想 用 Git 连接 Subversion 的 代码 仓库 ， 还 可 以 加 上 +svn 选项 ， 具 体 将 在 第 八 章 作 介绍 。 







































































1.4.4 在 Windows 上 安装 






































在 Windows 上 安装 Git 同样 轻松 ， 有 个 叫做 msysGit 的 项 目 提供 了 安装 包 ， 可 以 从 Google Code 的 页 面 
上 下 载 安装 文人 











ay 


(.exe) 





© Intradaczinn 
P? Destination Se 
& lnstallatea 


$ Install Gir instaer 1.6.0.5 


Dusem install am “Sears Computer” 
Parka: hare 

v! cr 

Amend PATH and MANPATH far git 


Action 
Metall 
irritall 


Werne 


Space emabed 10.8 ilk 


(Go Bark ) 





图 1.7: Git OS X 安装 工具 体 


http://code.google.com/p/msysgit 














完成 安装 之 后 ， 
Git 项 目 管理 工具 



































就 可 以 使 用 命令 行 的 git 














R (BA B I 











1.5 初次 运行 Git 前 的 配置 





一 般 在 新 的 系统 上 ， 我 们 都 需要 先 配 置 下 自己 的 Git 工 
现在 的 配置 。 当 然 ， 如 果 需 要 ， 你 随时 可 以 
Git 提供 了 一 个 叫做 git config 的 工具 (译注 : 











名 字 来 呼叫 此 命令 。 
各 个 环节 的 















































用 相同 的 命令 修改 已 有 的 配置 。 





















































企 环 境 。 配 置 工作 只 需 一 次 ， 


实际 是 git-config 命令 ， 
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14. CE 


[ Contin |) 


ssh 客户 端 了 ， 另 外 还 有 一 个 图 形 界 面 的 














以 后 升级 时 还 会 沿用 
































只 不 过 可 以 通过 git 加 一 个 


























) ， 专 门 用 来 配置 或 读 取 相应 的 工作 环境 变量 。 而 正 是 由 这 些 环境 变量 ， 








决定 了 Git 在 











具体 工作 方式 和 行为 。 这 些 变 量 可 以 存放 在 以 下 三 个 不 同 的 地 方 : 


























/etc/gitconfig 文 件 : f 统 
的 就 是 这 个 文件 。 





























~/.gitconfig 文 件 ， 用户 






































的 就 是 这 个 文件 。 
当前 项 目的 sit 目录 中 的 配置 文件 (也 就 是 工作 目录 中 的 .git/config WH 























对 所 有 用 户 都 普遍 适 





录 下 的 配置 文件 只 适用 于 该 用 户 。 








3 的 配置 。 若 使 
















































































用 git config 时 用 --system 选项 ， 读 写 


若 使 用 git config 时 用 --global 选项 ， 读 写 

















F) : 这 里 的 配置 仅仅 针对 当前 























项 目 有 效 。 每 一 个 级 别 的 配置 都 会 覆盖 上 层 的 相同 配置 ， 所 以 .git/config 里 的 配置 会 覆盖 /etc/gitconfig 


中 的 同名 变量 。 




















在 Windows 系统 上 ，Git 会 找寻 





IFE 














录 下 的 .gitconfig 文件 。 主 目 














什么 





H3, 











8 


























录 即 snome 变量 指定 的 目录 ， 一 般 都 
是 C:\Documents and Settings\$USER ° 此 外 ， Git 还 会 党 试 找寻 /etc/gitconfig 文件 ， 


就 以 此 作为 根 目录 来 定位 。 





只 不 过 看 当初 Git 装 在 
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1.5 初次 运行 Git 前 的 配 



























































































































































1.5.1 用 户 信息 

第 一 个 要 配置 的 是 你 个 人 的 用 户 名 称 和 电子 邮件 地 址 。 这 两 条 配置 很 重要 ， 每 次 cit 提交 时 都 会 引用 这 两 
条 信息 ， 说 明 是 谁 提交 了 更 新 ， 所 以 会 随 更 新 内 容 一 起 被 永久 纳入 历史 记录 : 
$ git config --global user.name "John Doe" 
$ git config --global user.email johndoe@example.com 

WRAT --global 选项 ， 那 么 更 改 的 配置 文件 就 是 位 于 你 用 户主 目录 下 的 那个 ， 以 后 你 所 有 的 项 目 都 会 默 
认 使 用 这 里 配置 的 用 户 信息 。 如 果 要 在 某 个 特定 的 项 目 中 使 用 其 他 名 字 或 者 电邮 ， 只 要 去 掉 --global 选项 重 
新 配置 即 可 ， 新 的 设 定 保 存在 当前 项 目的 .git/config 文件 里 。 

1.5.2 文本 编辑 器 

接 下 来 要 设置 的 是 默认 使 用 的 文本 编辑 器 。Git 需要 你 输入 一 些 额 外 消息 的 时 候 ， 会 自动 调用 一 个 外 部 文本 
编辑 器 给 你 用 。 默 认 会 使 用 操作 系统 指定 的 默认 编辑 器 ， 一 般 可 能 会 是 Vi 或 者 Vim。 如 果 你 有 其 他 偏好 ， 比 
如 Emacs 的 话 ， 可 以 重新 设置 : 





























$ git config --global core.editor emacs 


1.5.3 差异 分 析 工 具 


个 比较 常用 的 是 ， 








还 有 















































在 解决 合 

















冲突 时 使 























$ git config --global merge.tool vimdiff 










































































j 哪 种 差异 分 析 工 具 。 比 如 要 改 用 



















































































































































































vimdiff 的 话 : 


Git 可 以 理解 kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff，gvimdiff，ecmerge， 和 opendiff 等 
合并 工具 的 输出 信息 。 当 然 ， 你 也 可 以 指定 使 用 自己 开发 的 工具 ， 具 体 怎么 做 可 以 参阅 第 七 章 。 
1.5.4 查看 配置 信息 
要 检查 已 有 的 配置 信息 ， 可 以 使 用 git config -list MẸ: 
$ git config --list 
user.name-Scott Chacon 
user.email-schaconagmai]l.com 
color.status-auto 
color.branch-auto 
color.interactive-auto 
color.diff-auto 
有 时 候 会 看 到 重复 的 变量 名 ， 那 就 说 明 它 们 来 自 不 同 的 配置 文件 (比如 /etc/sitconfis 和 ~/.gitconfig) , ^^ 















































用 的 是 最 后 


个 。 








过 最 终 Git 实际 采 
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也 可 以 直接 查阅 某 个 环境 变量 的 设 定 ， 只 要 把 特定 的 名 字 跟 在 后 面 即 可 ， 像 这 样 : 























$ git config user.name 


Scott Chacon 


1.6 获取 帮助 


想 了 解 Git 的 各 式 

































































$ git help «verb» 
$ git «verb» --help 


$ man git-<verb> 


比如 ， 要 学 习 config 命令 可 以 怎么 用 ， 


$ git help config 





























该 怎么 用 ， 可 以 阅读 它们 的 使 用 帮助 ， 方 法 有 三 : 
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我 们 随时 都 可 以 浏览 这 些 帮 助 信息 而 无 需 连 网 。 不 过 ， 要 是 你 觉得 还 不 够 ， 可 以 到 Frenode IRC 服务 器 


bi 
(irc.freenode.net) 上 的 #git 或 #github 频道 寻求 他 人 帮助 。 这 两 个 频道 上 总 有 着 上 









































丰富 的 git AR, 























1.7 人 小结 





该 已 经 装 好 了 Git, 








HRI 


至 此 ， 你 该 对 Git 有 了 点 基本 的 


助人 。 

















tag 





























,的 名 字 和 电邮 。 接 下 来 让 我 
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认识 ， 包 括 它 和 以 前 你 使 用 的 CVCS 之 间 的 差别 。 现 在 ， 








号 人 ， 大 多 都 有 着 











在 你 的 系统 上 应 




















门 继续 学 习 Git 的 基础 





HAMIR o 




















Git 了 。 本 章 将 介绍 几 个 最 基本 的 ， 也 是 最 





Ud 


























|J 





读 完 本 章 你 就 能 上 手 使 用 
里 用 到 的 也 就 是 这 几 个 命令 。 
跟踪 茶 些 文件 ; 暂 存 或 提交 某 些 更 新 
件 ， 如 何 既 快 且 容易 地 撤消 犯 下 的 4 
从 远程 仓库 拉 数 据 下 来 或 者 推 数据 上 去 。 































































































































































































读 完 本 章 ， 你 就 能 
° 我 们 还 会 








初始 化 一 个 新 的 代码 
展示 如 何 让 Git 忽略 上 
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Ls 





库 ， 








的 Git MS, 


以 





bx 


做 一 





当 的 配置 


























后 绝 大 多 数 时 间 












































` 错 误 ， 如 何 浏 


WA 


RENIE, Bea 

















符合 特定 











网 项 



























































Hemant, Bek 







































































































































































次 更 新 之 间 












































始 或 停止 
模式 的 文 
的 差异 ; 以 及 如 何 































































































































































































































































































2.1 取得 项 目的 Git 仓库 
有 两 种 取得 Git 项 目 仓 库 的 方法 。 第 一 种 是 在 现存 的 目录 下 ， 通 过 导入 所 有 文件 来 创建 新 的 Git 仓库 。 第 
二 种 是 从 已 有 的 Git 仓库 克隆 出 一 个 新 的 镜像 仓库 来 。 
2.1.1 从 当前 目录 初始 化 
要 对 现 有 的 某 个 项 目 开 始 用 Git 管理 ， 只 需 到 此 项 目 所 在 的 目录 ， 执 行 
$ git init 
初始 化 后 ， 在 当前 目录 下 会 出 现 一 个 名 为 .git 的 目录 ， 所 有 Git 需要 的 数据 和 资源 都 存放 在 这 个 目录 
中 。 不 过 目前 ， 仅 仅 是 按照 既 有 的 结构 框架 初始 化 好 了 里 边 所 有 的 文件 和 目录 ， 但 我 们 还 没有 开始 跟踪 管理 项 
中 的 任何 一 个 文件 。 (在 第 九 章 我 们 会 详细 说 明 刚 才 创 建 的 .git 目录 中 究竟 有 哪些 文件 ， 以 及 都 起 些 什么 
EH °) 
如 果 当 前 目录 下 有 几 个 文件 想 要 纳入 版 本 控制 ， 需 要 先 用 git add 命令 告诉 Git 开始 对 这 些 文件 进行 跟 
踪 ， 然 后 提交 : 
$ git add *.c 


$ git add README 


$ git commit -m 'initial project version' 








A 

















稍 后 我 们 再 





解释 


^a. 
By: 





条 























Ap 



































令 的 意思 。 不 过 现在 ， 


你 


,经 得 到 了 一 个 实际 维 














护 着 若干 文人 


F 的 Git 仓库 。 
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2.1.2 从 现 有 仓库 克隆 


如 果 想 对 某 个 开源 项 目 出 一 份 力 ， 可 以 先 把 该 项 目的 Git 仓库 复制 一 份 出 来 ， 这 就 需要 用 到 git clone 命 
令 。 如 果 你 熟悉 其 他 的 VCS 比如 Subversion， 你 可 能 已 经 注意 到 这 里 使 用 的 是 clone 而 不 是 checkout。 这 
是 个 非常 重要 的 差别 ，Git 收取 的 是 项 目 历 史 的 所 有 数据 (每 一 个 文件 的 每 一 个 版 本 ) ， 服 务 器 上 有 的 数据 克 
隆之 后 本 地 也 都 有 了 “。 实 际 上 ， 即 便服 务 器 的 磁盘 发 生 故 障 ， 用 任何 一 个 克隆 出 来 的 客户 端 都 可 以 重建 服务 器 
上 的 仓库 ， 回 到 当初 克隆 时 的 状态 〈 可 能 会 丢失 某 些 服务 器 端的 挂钩 设置 ， 但 所 有 版 本 的 数据 仍旧 还 在 ， 有 关 
细节 请 参考 第 四 章 ) o 

克隆 仓库 的 命令 格式 为 sit clone [uri] ° 比如， 要 克隆 Ruby 语言 的 Git 代码 仓库 Grit， 可 以 用 下 面 的 命 


































































































































































































































































































wad vg 

























































































BR 



































$ git clone git://github.com/schacon/grit.git 


























































































































































































































这 会 在 当前 目录 下 创建 一 个 名 为 “grit” 的 目录 ， 其 中 内 含 一 个 .sit 的 目录 ， 并 从 同步 后 的 仓库 中 拉 出 
所 有 的 数据 ， 取 出 最 新 版 本 的 文件 拨 贝 。 如 果 进 入 这 个 新 建 的 srit 目录 ， 你 会 看 到 项 目 中 的 所 有 文件 已 经 在 
里 边 了 ， 淮 备 好 后 续 的 开发 和 使 用 。 如 果 希 望 在 克隆 的 时 候 ， 自 己 定义 要 新 建 的 项 目 目录 名 称 ， 可 以 在 上 面 的 

















































































































命令 最 后 指定 








git clone git://github.com/schacon/grit.git mygrit 






































唯一 的 差别 就 是 ， 现 在 新 建 的 目录 成 了 mygrit， 其 他 的 都 和 上 边 的 一 样 。 

Git 文 持 许多 数据 传输 协议 。 之 前 的 例子 使 用 的 是 git:// 协议 ， 不 过 你 也 可 以 用 http(s):// 或 者 usereserver:/ 
path.git 表示 的 SSH 传输 协议 。 我 们 会 在 第 四 章 详 细 介绍 所 有 这 些 协 议 在 服务 器 端 该 如 何 配置 使 用 ， 以 及 各 种 
方式 之 间 的 利弊 。 























































































































=> 








2.2 记录 每 次 更 新 到 仓库 


现在 我 们 手 上 已 经 有 了 一 个 真实 项 目的 Git 仓库 ， 并 从 这 个 仓库 中 取出 了 所 有 文件 的 工作 拷贝 。 接 下 来 ， 
对 这 些 文件 作 些 修改 ， 在 完成 了 一 个 阶段 的 目标 之 后 ， 提 交 本 次 更 新 到 仓库 。 
请 记 住 ， 工 作 目 录 下 面 的 所 有 文件 都 不 外 乎 这 两 种 状态 : 已 跟踪 或 未 跟踪 。 已 跟踪 的 文件 是 指 本 来 就 被 纳入 
版 本 控制 管理 的 文件 ， 在 上 次 快照 中 有 它们 的 记录 ， 工 作 一 段 时 间 后 ， 它 们 的 状态 可 能 是 未 更 新 ， 已 修改 或 者 
已 放 入 暂 存 区 。 而 所 有 其 他 文件 都 属于 未 跟踪 文件 。 它 们 既 没有 上 次 更 新 时 的 快照 ， 也 不 在 当前 的 暂 存 区 域 。 
初次 克隆 某 个 仓库 时 ， 工 作 目 录 中 的 所 有 文件 都 属于 已 跟踪 文件 ， 且 状态 为 未 修改 。 
在 编辑 过 某 些 文件 之 后 ，Git 将 这 些 文 件 标 为 已 修改 。 我 们 逐步 把 这 些 修改 过 的 文件 放 到 和 暂 存 区 域 ， 然 后 等 
最 后 一 次 性 提交 暂 存 区 域 的 所 有 文件 更 新 ， 如 此 重复 。 所 以 使 用 Git 时 的 文件 状态 变化 周期 如 图 2.1 所 示 。 

































































































































































































































































































































































































































































ned 
























































































































































2.2.1 检查 当前 文件 状态 












































要 确定 哪些 文件 当前 处 于 什么 状态 ， 可 以 用 git status 命令 。 如 果 在 克隆 仓库 之 后 立即 执行 此 命令 ， 会 看 
到 类 似 这 样 的 输出 : 
























































$ git status 
# On branch master 


nothing to commit (working directory clean) 
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File Status Lifecycle 





图 2.1: 文件 的 状态 变化 周期 














这 说 明 你 现在 的 工作 目录 相当 干净 。 换 句 话 说， 当前 没有 任何 跟踪 着 的 文件 ， 也 没有 任何 文件 在 上 次 提交 后 
更 改过 。 此 外 ， 上 面 的 信息 还 表明 ， 当 前 目录 下 没有 出 现任 何 处 于 未 跟踪 的 新 文件 ， 否 则 Git 会 在 这 里 列 出 
来 。 最 后 ， 该 命令 还 显示 了 当前 所 在 的 分 支 是 master， 这 是 默认 的 分 支 名 称 ， 实 际 是 可 以 修改 的 ， 现 在 不 必 
多 虑 。 下 一 章 我 们 就 会 详细 讨论 分 文 和 引用 。 

现在 让 我 们 用 vim 编辑 一 个 新 文件 README， 保 存 退出 后 运行 git status 会 看 到 该 文件 
表 中 : 
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EE 





现在 未 跟踪 文件 列 












































$ vim README 
$ git status 
# On branch master 


# Untracked files: 


# (use "git add <file>..." to include in what will be committed) 
# 
# README 


nothing added to commit but untracked files present (use "git add" to track) 








就 是 在 “Untracked files" XF PM ° Git 不 会 自动 将 之 纳入 跟踪 范围 ， 除 非 你 明明 白白 地 告诉 它 这 人 么 
做 ， 因 而 不 用 担心 把 临时 文件 什么 的 也 归 入 版 本 管理 。 不 过 现在 我 们 确实 想 要 跟踪 管理 README 这 个 文件 。 






































> 























2.2.2 跟踪 新 文件 
使 用 命令 wiv add 开始 跟踪 一 个 新 文件 。 所 以 ， 要 跟踪 README 文件 ， 运 行 : 























$ git add README 











此 时 再 运行 zit status 命令 ， 会 看 到 README 文件 已 被 跟踪 ， 并 处 于 暂 存 状态 : 


























$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 
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# new file: 


# 
































基础 
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README 
































































































































































































































































































































































































































































































































































































































只 要 在 “Changes to be committed” 这 行 下 面 的 ， 就 说 明 是 已 暂 存 状态 。 如 果 此 时 提交 ， 那 么 该 文件 此 
时 此 刻 的 版 本 将 被 留存 在 历史 记录 中 。 你 可 能 会 想起 之 前 我 们 使 用 git init 后 就 运行 了 git add 命令 ， 开 始 跟 
踪 当 前 目录 下 的 文件 。git add 后 可 以 接 要 跟踪 的 文件 或 目录 的 路 径 。 如 果 是 目录 的 话 ， 就 说 明 要 递归 跟踪 所 
有 该 目录 下 的 文件 。 

2.9.8. Hd EE EXE 

现在 我 们 修改 下 之 前 已 跟踪 过 的 文件 benchmarks.rb， 然 后 再 次 运行 status 命令 ， 会 看 到 这 样 的 状态 报告 : 
$ git status 
# On branch master 
# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# 

# new file: README 

# 

# Changed but not updated: 

# (use "git add <file>..." to update what will be committed) 
# 

# modified: ^ benchmarks.rb 

# 

文件 benchmarks.rb 出 现在 “Changed but not updated" 这 行 下 面 ， 说 明 已 跟踪 文件 的 内 容 发 生 了 变 
化 ， 但 还 没有 放 到 和 暂 存 区 。 要 和 暂 存 这 次 更 新 ， 需 要 运行 git add 命令 〈 这 是 个 多 功能 命令 ， 根 据 目 标 文 件 的 状 
态 不 同 ， 此 命令 的 效果 也 不 同 : 可 以 用 它 开始 跟踪 新 文件 ， 或 者 把 已 跟踪 的 文件 放 到 暂 存 区 ， 还 能 用 于 合并 时 
把 有 冲突 的 文件 标记 为 已 解决 状态 等 ) 。 现 在 让 我 们 运行 sit ada 将 benchmarks.rb 放 到 暂 存 区 ， 然 后 再 看 
看 git status 的 输出 : 
$ git add benchmarks.rb 
$ git status 
# On branch master 
# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 

# new file: | README 

# modified: ^ benchmarks.rb 

# 

EATEN SCP REE, BIKERS LA FIC RICE » fux, MARE benchmarks.rb 里 再 加 条 
注释 ， 重 新 编辑 存盘 后 ， 准 备 好 提交 。 不 过 且慢 ， 再 运行 it status 看 看 
























































$ vim benchmarks .rb 


$ git status 
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# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 

# new file: README 

# modified: ^ benchmarks.rb 

# 

# Changed but not updated: 


# (use "git add <file>..." to update what will be committed) 
# 

# modified: ^ benchmarks.rb 

# 


















































LĒ! benchmarks.rb 文件 出 现 了 两 次 ! 一 次 算 未 暂 存 ， 一 次 算 已 暂 存 ， 这 怎么 可 能 昵 ? 好 吧 ， 实 际 上 Git 
只 不 过 暂 存 了 你 运行 git add 命令 时 的 版 本 ， 如 果 现 在 提交 ， 那 么 提交 的 是 添加 注释 前 的 版 本 ， 而 非 当 前 工 
作 目 录 中 的 版 本 。 所 以 ， 运 行 了 git add 之 后 又 作 了 修订 的 文件 ， 需 要 重新 运行 git ada 把 最 新 版 本 重新 暂 存 


HES: 











































































































































































































$ git add benchmarks.rb 

$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 

# new file: README 

# modified: ^ benchmarks.rb 

# 


2.2.4 忽略 某 些 文件 





























一 般 我 们 总 会 有 些 文 件 无 需 纳 入 Git 的 管理 ， 也 不 希望 它们 总 出 现在 未 跟踪 文件 列表 。 通 常 都 是 些 自动 生 
成 的 文件 ， 像 是 日 志 或 者 编译 过 程 中 创建 的 等 等 。 我 们 可 以 创建 一 个 名 为 .gitignore 的 文件 ， 列 出 要 忽略 的 
文件 模式 ， 来 看 一 个 简单 的 例子 : 





























































































































$ cat .gitignore 


* [oa] 


k~ 















































第 一 行 告 诉 Git 忽略 所 有 以 .o 或 .a 结尾 的 文件 。 一 般 这 类 对 象 文件 和 存档 文件 都 是 编译 过 程 中 出 现 

的 ， 我 们 用 不 着 跟踪 它们 的 版 本 。 第 二 行 告诉 Git 忽略 所 有 以 波浪 符 C) 结尾 的 文件 ， 许 多 文本 编辑 软件 

(比如 Emacs) 都 用 这 样 的 文件 名 保存 副本 。 此 外 ， 你 可 能 还 需要 忽略 log, tmp 或 者 pid 目录 ， 以 及 自动 

生成 的 文档 等 等 。 要 养 成 一 开始 就 设置 好 .gitignore 文件 的 习惯 ， 以 免 将 来 误 提交 这 类 无 用 的 文件 。 
文件 .gitignore 的 格式 规范 如 下 : 

















































































































































































































所 有 空 行 或 者 以 注释 符号 € 开头 的 行 都 会 被 Git 忽略 。 
可 以 使 用 标准 的 glob 模式 匹配 。 
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匹配 模式 最 后 跟 反 斜 杜 (/) 说 明 要 忽略 的 是 目录 。 
要 忽略 指定 模式 以 外 的 文件 或 目录 ， 可 以 在 模式 前 加 上 惊叹 号 (0) 取 反 。 
所 谓 的 glob 模式 是 指 shell 所 使 用 的 简化 了 的 正则 表达 式 。 星 号 (*) 匹配 零 个 或 多 个 任意 字符 ; [abc] 匹配 
王 何 一 个 列 在 方 括号 中 的 字符 (这 个 例子 要 么 匹配 一 个 a, M 各 一 个 b， 要 么 匹配 一 个 c) ; 问号 (? 
只 匹配 一 个 任意 字符 ; 如 果 在 方 括号 中 使 用 短 划 线 分 隅 两 个 字符 ， 表 示 所 有 在 这 两 个 字符 范围 内 的 都 可 以 匹配 
(比如 [0-9] 表示 匹 配 所 有 0 到 9 的 数字 ) 。 
我 们 再 看 一 个 .gitignore 文件 的 例子 : 





























# 此 为 注释 一 将 被 Git 忽略 
.a # 忽略 所 有 .a 结尾 的 文件 


* 


llib.a #412 lib.a 除外 
/TODO # 仅仅 忽略 项 目 根 目录 下 的 TODO 文件 ， 不 包括 subdir/TODO 
build/ # 忽略 build/ 目录 下 的 所 有 文件 


doc/*.txt # 会 忽略 doc/notes.txt 但 不 包括 doc/server/arch.txt 


2.2.55 查看 已 暂 存 和 未 暂 存 的 更 新 












































实际 上 git status 的 显示 比较 简单 ， 


git diff 命令 。 稍 后 我 们 会 详细 介绍 sit diff, 





























H 











经 能 


FEME, È 










































































仅仅 是 列 出 了 修改 过 的 文件 ， 如 果 要 
答 我 们 






































新 还 没有 和 暂 存 ? 有 哪些 更 新 已 经 和 暂 存 起 来 准 
删除 的 行 。 





好 了 下 次 提交 ? 





















































假如 再 次 修改 README 文件 后 暂 存 ， 然 后 编辑 benchmarks.rb 文件 





























到 : 


$ git status 

# On branch master 

# Changes to be committed: 
# (use 
# 

# new file: 
# 

# Changed but not updated: 
# (use 
# 

# modified: 
# 


"git reset HEAD <file>..." to unstage) 


README 


"git add <file>..." to update what will be committed) 


benchmarks .rb 












































要 查看 尚未 暂 存 的 文件 更 新 了 哪些 部 分 ， 不 加 参数 





























$ git diff 

diff --git a/benchmarks.rb b/benchmarks.rb 
index 3cb747f..da65585 100644 

--- a/benchmarks.rb 

+++ b/benchmarks.rb 


@@ -36,6 +36,10 @@ def main 





看 具体 修改 了 什么 地 方 ， 

















个 问题 了 : 





当前 作 的 哪些 更 








可 以 用 





























git diff 全 使 























接 输 入 git diff: 














用 文件 补丁 的 格式 显示 有 具体 添加 和 











HIF, 运行 Status 命令 ， 


AE 
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Gcommi t. parents[0].parents[0].parents[0] 


end 
* run code(x, ‘commits 1') do 
ar git.commits.size 
En end 


run code(x, 'commits 2') do 
log = git.commits('master', 15) 


log.size 










































































此 命令 比较 的 是 工作 目录 中 当前 文件 和 暂 存 区 域 快照 之 间 的 差异 ， 也 就 是 修改 之 后 还 没有 暂 存 起 来 的 变化 内 
容 。 
若 要 看 已 经 暂 存 起 来 的 文件 和 上 次 提交 时 的 快照 之 间 的 差异 ， 可 以 用 git aise -cached 命令 。 (Git 1.6.1 








































































































及 更 高 版 本 还 允许 使 用 git diff --staged， 歼 果 是 相同 的 ， 但 mos 。) 来 看 看 实际 的 效果 : 



































$ git diff --cached 

diff --git a/README b/README 
new file mode 100644 

index 0000000. .03902al 

--- /dev/null 

+++ b/README2 

@@ -0,0 +1,5 @@ 

t+grit 

+ by Tom Preston-Werner, Chris Wanstrath 
+ http://github.com/mojombo/grit 
i 


+Grit is a Ruby library for extracting information from a Git repository 






































请 注意 ， l git diff 不 过 是 显示 还 没有 暂 存 起 来 的 改动 ， 而 不 是 这 次 工作 和 上 次 提交 之 间 的 差异 。 所 以 有 
时 候 你 一 下 子 暂 存 了 所 有 更 新 过 的 文件 后 ， 运 行 sit diff 后 却 什么 也 没有 ， 就 是 这 个 原因 。 
像 之 前 说 的 ， 暂 存 benchmarks.rb 后 再 编辑 ， 运 行 sit status. 会 看 到 暂 存 前 后 的 两 个 版 本 : 



















































































































































































$ git add benchmarks.rb 

$ echo '# test line' >> benchmarks.rb 
$ git status 

# On branch master 

# 

# Changes to be committed: 
# 

# modified: ^ benchmarks.rb 
# 

# Changed but not updated: 
# 

# modified: benchmarks. rb 
# 








现在 运行 git diff 看 暂 存 前 后 的 变化 : 
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$ git diff 


diff --git a/benchmarks.rb b/benchmarks.rb 
index e445e28..86b2f7c 100644 


--- a/benchmarks.rb 


+++ b/benchmarks.rb 


eo -127,3 +127,4 @@ end 


main() 


##pp Grit::GitRuby.cache client.stats 


+# test line 


and git diff --cached to see what you’ ve staged so far: 
$ git diff --cached 
diff --git a/benchmarks.rb b/benchmarks.rb 
index 3cb747f..e445e28 100644 


--- a/benchmarks.rb 


+++ b/benchmarks.rb 
@@ -36,6 -36,10 @@ def main 
Gcommi t.parents[0].parents[0].parents[0] 


end 
* run code(x, ‘commits 1') do 
ap git.commits.size 
E end 


run code(x, 'commits 2') do 


log = git.commits('master', 15) 


log.size 


2.2.6 提交 更 新 





现在 的 暂 存 


x 








域 已 经 准 












































git add x, 否则 


























下 ， 是 不 是 都 





暂 存 起 来 





$ git commit 


























备 妥 当 可 以 提交 了 。 在 此 之 前 ， 请 一 定 要 确认 还 有 什么 修改 过 的 或 新 建 的 文件 还 没有 


提交 的 时 候 不 会 记录 这 些 还 没 暂 存 起 来 的 变化 。 所 以 ， 每 次 准备 提交 前 ， 先 用 sit status 看 
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可 然后 再 运行 提交 命令 git commit: 














这 种 方式 会 启动 文本 








软件 ， 一 般 都 是 


























vim 或 














设 定 你 喜欢 的 














VEIT o 

































































) 


























编辑 器 会 显示 类 似 下 






































下 的 文本 信息 (本 例 选用 Vim 的 屏 显 方式 展示 ) 


# Please enter the commit message for your changes. Lines starting 


# with '£' will be ignored, and an empty message aborts the commit. 


# On branch master 


# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 
# 
# new file: | README 
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ij 辑 器 以 便 输入 本 次 提交 的 说 明 。 (默认 会 启用 shell 的 环境 变量 SEDITOR 所 指定 的 
emacs。 当 然 也 可 以 按照 第 一 章 介 绍 的 方式 ， 使 用 


git config --global core.editor 命令 
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# modified: ^ benchmarks.rb 


".git/COMMIT EDITMSG" 10L, 283C 


















































可 以 看 到 ， 默 认 的 提交 消息 包含 最 后 一 次 运行 sit status 的 输出 ， 放 在 注释 行 里 ， 另 外 开头 还 有 一 空 行 ， 供 
你 输入 提交 说 明 。 你 完全 可 以 去 掉 这 些 注 释 行 ， 不 过 留 着 也 没关系 ， 多 少 能 帮 你 回想 起 这 次 更 新 的 内 容 有 哪 
些 。 (如 果 觉 得 这 还 不 够 ， 可 以 用 -. 选项 将 修改 差异 的 每 一 行 都 包含 到 注释 中 来 。) 退出 编辑 器 时 ，Git 会 
丢掉 注释 行 ， 将 说 明 内 容 和 本 次 更 新 提交 到 仓库 。 
也 可 以 使 用 -m 参数 后 跟 提 交 说 明 的 方式 ， 在 一 行 命令 中 提交 更 新 : 


































































































































































































































































































$ git commit -m "Story 182: Fix benchmarks for speed" 





[master]: created 463dc4f: "Fix benchmarks for speed" 
2 files changed, 3 insertions(+), 0 deletions(-) 
create mode 100644 README 




















好 ， 现 在 你 已 经 创建 了 第 一 个 提交 ! 可 以 看 到 ， 提 交 后 它 会 告诉 你 ， 当 前 是 在 哪个 分 支 (master) 提交 的 ， 
E E 以 及 在 本 次 提交 中 ， 有 多 少 文件 修订 过 ， 多 少 行 添 改 和 删 

























































































ae 提交 时 记录 的 是 放 在 暂 存 区 域 的 快照 ， 任 何 还 未 暂 存 的 仍然 保持 已 修改 状态 ， 可 以 在 下 次 提交 时 纳入 
版 本 管理 。 每 一 次 运行 提交 操作 ， 都 是 对 你 项 目 作 一 次 快照 ， 以 后 可 以 回 到 这 个 状态 ， 或 者 进行 比较 。 































































































2.2.7 跳 过 使 用 暂 存 区 域 


尽管 使 用 暂 存 区 域 的 方式 可 以 精心 准备 要 提交 的 细节 ， 但 有 时 候 这 么 做 略 显 繁琐 。Git 提供 了 一 个 跳 过 使 用 
暂 存 区 域 的 方式 ， 只 要 在 提交 的 时 候 ， 给 eit comit 加 上 -a BR, Git 就 会 自动 把 所 有 已 经 跟踪 过 的 文件 暂 
年 起 来 一 并 提交 ， 从 而 跳 过 git aaa 步骤 : 
























































































































































$ git status 


# On branch master 


# 

# Changed but not updated: 
# 

# modified: ^ benchmarks.rb 
# 


$ git commit -a -m ‘added new benchmarks ' 
[master 83e38c7] added new benchmarks 
1 files changed, 5 insertions(+), 0 deletions(-) 














看 到 了 吗 ? 提交 之 前 不 再 需要 git ada 文件 benchmarks.rb J ° 


























2.2.8 移 除 文件 


要 从 Git 中 移 除 某 个 文件 ， 就 必须 要 从 已 跟踪 文件 清单 中 移 除 (确切 地 说 ， 是 从 暂 存 区 域 移 除 ) ， 然 后 提 
交 。 可 以 用 sit rm 命令 完成 此 项 工作 ， 并 连带 从 工作 目录 中 删除 指定 的 文件 ， 这 样 以 后 就 不 会 出 现在 未 眼 踪 
文件 清单 中 了 。 
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运行 sit status 时 就 会 在 "Changed but not updated" 部 


T 











如 果 只 是 简单 地 从 工作 目录 中 手工 删除 文件 ， 
分 (也 就 是 未 暂 存 清单 ) 看 到 : 






















































































$ rm grit.gemspec 
$ git status 


# On branch master 


# 

# Changed but not updated: 

# (use "git add/rm <file>..." to update what will be committed) 
# 

# deleted: grit.gemspec 

# 











然后 再 运行 git rm 记录 此 次 移 除 文件 的 操作 : 




















$ git rm grit.gemspec 

rm 'grit.gemspec' 

$ git status 

# On branch master 

# 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 


# 
# deleted: grit.gemspec 
# 


















































chad 


























最 后 提交 的 时 候 ， 该 文件 就 不 再 纳入 版 本 管理 了 。 如 果 删 除 之 前 修改 ; 已 经 放 到 和 暂 存 区 域 的 话 ， 则 必须 
要 用 强制 删除 选项 -f (译注 : 即 force 的 首 字 母 ) ， 以 防 误 删 除 文件 修改 的 内 容 。 
另外 一 种 情况 是 ， 我 们 想 把 文件 从 Git 仓库 中 删除 〈《 亦 即 从 暂 存 区 域 移 除 ) ， 但 仍然 希望 保留 在 当前 工作 
录 中 。 换 句 话 说， 仅 是 从 跟踪 请 单 中 删除 。 比 如 一 些 大 型 日 志文 件 或 者 一 堆 .a 编译 文件 ， 不 小 心 纳 入 仓库 
后 ， 要 移 除 跟踪 但 不 删除 文件 ， 以 便 稍 后 在 .gitignore 文件 中 补 上 ， 用 --cached 选项 即 可 : 


















































$ 
Hm 

















































































































































































































































































































$ git rm --cached readme.txt 





























后 面 可 以 列 出 文件 或 者 目录 的 名 字 ， 也 可 以 使 用 glob 模式 。 比 方 说 : 
































$ git rm log/A*.1log 









































注意 到 星 号 * 之 前 的 反 斜 枉 \， 因 为 Git 有 它 自 己 的 文件 模式 扩展 匹配 方式 ， 所 以 我 们 不 用 shell 来 帮 
CRF (PAE: 实际 上 不 加 反 和 斜 杠 也 可 以 运行 ， 只 不 过 按照 shell 扩展 的 话 ， 仅 仅 删 除 指定 目录 下 的 文件 而 
不 会 递归 匹配 。 上 面 的 例子 本 来 就 指定 了 目录 ， 所 以 效果 等 同 ， 但 下 面 的 例子 就 会 用 递归 方式 匹配 ， 所 以 必须 
TRL ©) 。 此 命令 删除 所 有 1os/ 目录 下 扩展 名 为 .log 的 文件 。 类 似 的 比如 : 
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VF 
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rit 
mh 
aii 
B 
SH 
E 
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e 


git rm \*~ 




















AN 
X 



































会 递归 删除 当前 目录 及 3 所 有 ~ 结尾 的 文件 。 











2.2.9 移动 文件 


不 像 其 他 的 VCS 系统 ，Git 并 不 跟踪 文件 移动 操作 。 如 果 在 Git FEMNA I 蒜 中 存储 的 元 数 
据 并 不 会 体现 出 这 是 一 次 改名 操作 。 不 过 Git 非常 聪明 ， 它 会 推断 出 究竟 发 生 了 什么 ， 至 于 具体 是 如 何 做 到 
的 ， 我 们 稍 后 再 谈 。 
既然 如 此 ， 当 你 看 到 Git 的 mv 命令 时 一 定 会 困惑 不 已 。 要 在 Git 中 对 文件 改名 ， 可 以 这 么 做 : 



























































个 文件 ， 仓 


-一 













































































































































































$ git mv file from file to 














Tt 












































rT es 
ES 


imli 
pug 
a 


恰 如 预 期 般 正 常 工作 。 实 际 上 ， 即 便 此 时 查看 状态 信息 ， 也 会 明白 无 误 地 看 到 关 了 








命名 操作 的 说 明 : 












































$ git mv README.txt README 

$ git status 

# On branch master 

# Your branch is ahead of 'origin/master' by 1 commit. 
# 

# Changes to be committed: 




















# (use "git reset HEAD <file>..." to unstage) 
# 
# renamed: README.txt -> README 
# 
E ^ : > L Mem AN 
LX, SÍT git mv 就 相当 于 运行 了 下 面 三 条 命令 : 
































$ mv README.txt README 
$ git rm README .txt 
$ git add README 












































如 此 分 开 操 作 ，Git 也 会 意识 到 这 是 一 次 改名 ， 所 以 不 管 何 种 方式 都 一 样 。 当 然 ， 直 接 用 eit m 轻便 得 
多 ,不 过 有 时 候 用 其 他 工具 批 处 理 改 名 的 话 ， 要 记得 在 提交 前 删除 老 的 文件 名 ， 再 添加 新 的 文件 名 。 



























































































































































2.3 查看 提交 历史 


在 提交 了 若干 更 新 之 后 ， 又 或 者 克隆 了 某 个 项 目 ， 想 回顾 下 提交 历史 ， 可 以 使 用 eit los 命令 。 
接 下 来 的 例子 会 用 我 专门 用 于 演示 的 simplegit 项 目 ， 运 行 下 面 的 命令 获取 该 项 目 源 代码 ; 
















































































































































































git clone git://github.com/schacon/simplegit-progit.git 
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然后 在 此 项 目 中 运行 git log， 应 该 会 看 到 下 面 















































$ git log 
commit ca82a6dff817ec66f44342007202690a93763949 
Author: Scott Chacon <schacon@gee-mail.com> 


Date: Mon Mar 17 21:52:11 2008 -0700 

changed the verison number 
commit 085bb3bcb608ele8451d4b2432f8ecbe6306e7e7 
Author: Scott Chacon <schacon@gee-mail.com> 
Date: Sat Mar 15 16:40:33 2008 -0700 

removed unnecessary test code 
commit allbef06a3f659402fe7563abf99ad00de2209e6 
Author: Scott Chacon <schacon@gee-mail.com> 


Date: Sat Mar 15 10:31:28 2008 -0700 


first commit 








F 








默认 不 用 任何 参数 的 话 ，git log 会 按 提交 




























































































更 新 都 有 一 个 SHA-1 校 验 和 、 作 者 的 名 字 和 























1 
git log 有 许多 选项 可 以 帮助 你 搜寻 感 兴趣 的 提 




















Scott Chacon Pro Git 

















新 排 在 最 上 面 。 看 到 了 吗 ， 每 次 









































个 段落 显示 提交 说 明 。 





接 下 来 我 们 介绍 些 最 常 



























































我 们 常用 -p 选项 展开 显示 每 次 提交 的 内 容 差异 ， 


$ git log —p -2 
commit ca82a6dff817ec66f44342007202690a93763949 
Author: Scott Chacon <schacon@gee-mail.com> 


Date: Mon Mar 17 21:52:11 2008 -0700 


changed the verison number 


diff --git a/Rakefile b/Rakefile 

index a874b73..8f94139 100644 

--- a/Rakefile 

+++ b/Rakefile 

@@ -5,7 +5,7 @@ require 'rake/gempackagetask' 


spec = Gem::Specification.new do |s| 


x s.version = KOTIRO 
ap s.version = PO) E ER 
s.author = "Scott Chacon" 


commit 085bb3bcb608ele8451d4b2432f8ecbe6306e7e7 
Author: Scott Chacon <schacon@gee-mail.com> 


Date: Sat Mar 15 16:40:33 2008 -0700 
removed unnecessary test code 
diff --git a/lib/simplegit.rb b/lib/simplegit.rb 


index a0a60ae..47c6340 100644 
--- a/lib/simplegit.rb 
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TAS Hh : 
时 间 列 出 所 有 的 更 新 ， 最 近 的 更 
PRP HE ` PECETI], Belay 


















































j -2 则 仅 显示 最 近 的 
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Scott Chacon Pro Git 2.397 


rit 
m 
aii 
B 
SH 
E 





+++ b/lib/simplegit.rb 
@@ -18,8 +18,3 @@ class SimpleGit 


end 


end 

-if $0 == FILE _ 

- git = SimpleGit.new 
- puts git.show 

-end 


\ No newline at end of file 















































在 做 代码 审查 ， 或 者 要 快速 浏览 其 他 协作 者 提交 的 更 新 都 作 了 哪些 改动 时 ， 就 可 以 用 这 个 选项 。 此 外 ， 还 
午 多 摘要 选项 可 以 用 ， 比 如 --stat， 仅 显示 简要 的 增 改 行 数 统计 ; 
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Sie 





$ git log --stat 
commit ca82a6dff817ec66f44342007202690a93763949 
Author: Scott Chacon <schacon@gee-mail.com> 


Date: Mon Mar 17 21:52:11 2008 -0700 


changed the verison number 


Rakefile | Qa 


1 files changed, 1 insertions(+), 1 deletions(-) 
commit 085bb3bcb608ele8451d4b2432f8ecbe6306e7e7 


Author: Scott Chacon <schacon@gee-mail.com> 


Date: Sat Mar 15 16:40:33 2008 -0700 


removed unnecessary test code 


lib/simplegit.rb | 5. ----— 


1 files changed, 0 insertions(+), 5 deletions(-) 
commit allbef06a3f659402fe7563abf99ad00de2209e6 
Author: Scott Chacon <schacon@gee-mail.com> 


Date: Sat Mar 15 10:31:28 2008 -0700 


first commit 


README | 6 ++++++ 
Rakefile | 23 十 + 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
lib/simplegit.rb | 25 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 


3 files changed, 54 insertions(*), 0 deletions(-) 


















































每 个 提交 都 列 出 了 修改 过 的 文件 ， 以 及 其 中 添加 和 移 除 的 行 数 ， 并 在 最 后 列 出 所 有 增 减 行 数 小 计 。 

还 有 个 常用 的 --pretty 选项 ， 可 以 指定 使 用 完全 不 同 于 默认 格式 的 方式 展示 提交 历史 。 比 如 用 oneline 将 每 
个 提交 放 在 一 行 显示 ， 这 在 提交 数 很 大 时 非常 有 用 。 男 外 还 有 short, fu 和 fuer 可 以 用 ， 展示 的 信息 或 多 
或 少 有 些 不 同 ， 请 自己 动手 实践 一 下 看 看 效果 如 何 。 
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$23: Git 基础 Scott Chacon Pro Git 


$ git log --pretty-oneline 

ca82a6dff817ec66£44342007202690a93763949 changed the verison number 
085bb3bcb608ele8451d4b2432f8ecbe6306e7e7 removed unnecessary test code 
allbef06a3f659402fe7563abf99ad00de2209e6 first commit 





















































但 最 有 意思 的 是 format， 可 以 定制 要 显示 的 记录 格式 ， 这 样 的 输出 便于 后 期 编程 提取 分 析 ， 像 这 样 : 
































$ git log --pretty=format:"%h - %an, %ar : %s" 
ca82a6d - Scott Chacon, 11 months ago : changed the verison number 
085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code 


allbefO - Scott Chacon, 11 months ago : first commit 






































表 2.1 列 出 了 常用 的 格式 占 位 符 写法 及 其 代表 的 意义 。 
















































































































































































































































































选项 说 明 

%H 提交 对 象 (commit) 的 完整 哈 希 字 串 
%h 提交 对 象 的 简短 哈 希 字 串 

NT 树 对 象 (tree) 的 完整 哈 硕 字 串 

we PRY SR BU f] AGI AB 

7 父 对 象 (parent) MERRER 

xp 父 对 象 的 简短 哈 希 字 串 

%an 作者 (author) 的 名 字 

wae E 者 的 电子 邮件 地 址 

%ad FE 者 修订 日 期 (可 以 用 -date= 选项 定制 格式 ) 
War FE 者 修订 日 期 ， 按 多 和 久 以 前 的 方式 显示 
%cn 提交 者 (committer) 的 名 字 

%ce 提交 者 的 电子 邮件 地 址 

%cd 提交 日 期 

%cr 提交 日 期 ， 按 多 久 以 前 的 方式 显示 

%s 提交 说 明 





Ao 2.1: 




















尔 一 定 奇怪 _ 作 者 (author) _ 和 _ 提交 者 (committer) _ 之 间 究 竟 有 何 差别 ， 其 实 作者 指 的 是 实际 作出 修改 
的 人 ， 提 交 者 指 的 是 最 后 将 此 工作 成 果 提 交 到 仓库 的 人 。 所 以 ， 当 你 为 某 个 项 目 发 去 补丁 ， 然 后 某 个 核心 成 员 
将 你 的 补丁 并 入 项 目 时 ， 你 就 是 作者 ， 而 那个 核心 成 员 就 是 提交 者 。 我 们 会 在 第 五 章 再 详细 介绍 
致 差别 。 
H oneline 或 format 时 结合 --graph 选项 ， 可 以 看 到 开头 多 出 一 些 ASCIT 字符 串 表示 的 简单 图 形 
地 展示 了 每 个 提交 所 在 的 分 支 及 其 分 化 衍 合 情况 。 在 我 们 之 前 提 到 的 Grit 项 目 仓库 中 可 以 看 到 |: 































































































































































































































































































































































































$ git log --pretty=format:"%h %s" --graph 
* 2d3acf9 ignore errors from SIGCHLD on trap 


* 


IN 


5e3eell Merge branch 'master' of git://github.com/dustin/grit 
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Scott Chacon Pro Git 2.39 查看 提交 历史 





| * 420eac9 Added a method for getting the current branch. 
* | 30e367c timeout code and tests 

* | 5209431 add timeout protection to grit 

* | e1193f8 support for heads with slashes in them 

|/ 

* d6016bc require time for xmlschema 


* lldl9le Merge branch 'defunkt' into local 
























































以 上 只 是 简单 介绍 了 一 些 git log 命令 文 持 的 选项 。 表 2.2 还 列 出 了 一 些 其 他 常用 的 选项 及 其 释义 。 









































选项 说 明 

-p 按 补丁 格式 显示 每 个 更 新 之 间 的 差异 。 

--stat 显示 每 次 更 新 的 文件 修改 统计 信息 。 

--shortstat 只 显示 --stat 中 最 后 的 行 数 修改 添加 移 除 统计 。 

--name-only 仅 在 提交 信息 后 显示 已 修改 的 文件 清单 。 

--name-status 显示 新 增 、 人 修改、 删除 的 文件 清单 。 

--abbrev-commit 仅 显 示 SHA-1 的 前 几 个 字符 ， 而 非 所 有 的 40 个 字符 。 

--relative-date 使 用 较 短 的 相对 时 间 显 示 (比如 ， “2 weeks ago" ) » 

--graph 显示 ASCII 图 形 表示 的 分 支 合并 历史 。 

--pretty 使 用 其 他 格式 显示 历史 提交 信息 。 可 用 的 选项 包括 oneline，short，full，fuller 和 format (后 跟 指定 格式 ) ° 


2.3.1 限制 输出 长 度 


除了 定制 输出 格式 的 选项 之 外 ，git log 还 有 许多 非常 实用 的 限制 输出 长 度 的 选项 ， 也 就 是 只 输出 部 分 提交 
言 息 。 之 前 我 们 已 经 看 到 过 -2 了 ， 它 只 显示 最 近 的 两 条 提交 ， 实 际 上 ， 这 是 -<n> 选项 的 写法 ， 其 中 的 an 可 
以 是 任何 自然 数 ， 表 示 仅 显示 最 近 的 若干 条 提交 。 不 过 实践 中 我 们 是 不 太 用 这 个 选项 的 ，Git 在 输出 所 有 提交 
时 会 自动 调用 分 页 程序 (pager) ， 要 看 更 早 的 更 新 只 需 翻 到 下 页 即 可 。 
另外 还 有 按照 时 间作 限制 的 选项 ， 比 如 --since 和 --until。 下 面 的 命令 列 出 所 有 最 近 两 周 内 的 提交 : 
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$ git log --since-2.weeks 















































你 可 以 给 出 各 种 时 间 格 式 ， 比 如 说 具体 的 某 一 天 ( "2008-01-15" ) ， 或 者 是 多 和 久 以 前 〈 “2 years 1 day 
3 minutes ago" o 
还 可 以 给 出 若干 搜索 条 件 ， 列 出 符合 的 提交 。 用 --author 选项 显示 指定 作者 的 提交 ， 用 --grep 选项 搜索 







































































提交 说 明 中 的 关键 字 。 (请 注意 ， 如 果 要 得 到 同时 满足 这 两 个 选项 搜索 条 件 的 提交 ， 就 必须 用 --all-match 选 
项 。 
如 果 只 关心 某 些 文件 或 者 目录 的 历史 提交 ， 可 以 在 git log 选项 的 最 后 指定 它们 的 路 径 。 因 为 是 放 在 最 后 位 
置 上 的 选项 ， 所 以 用 两 个 短 划 线 (--) 隔 开 之 前 的 选项 和 后 面 限定 的 路 径 名 。 

K 2.3 还 列 出 了 其 他 常用 的 类 似 选 项 。 


































































































































































































选项 说 明 

-(n) 仅 显示 最 近 的 n 条 提交 

--since, --after 仅 显 示 指定 时 间 之 后 的 提交 。 
--until, --before 仅 显 示 指 定时 间 之 前 的 提交 。 
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$23 Git 基础 Scott Chacon Pro Git 


--author 仅 显 示 指定 作者 相关 的 提交 。 
--committer 和 仅 显示 指定 提交 者 相关 的 提交 。 





















































来 看 一 个 实际 的 例子 ， 如 果 要 查看 Git 仓库 中 ，2008 年 10 月 期 间 ，Junio Hamano 提交 的 但 未 合并 的 测 
试 脚 本 (位 于 项 目的 t/ 目录 下 的 文件 ) ， 可 以 用 下 面 的 查询 命令 















































































































































$ git log --pretty="%h:%s" --author-gitster --since-"2008-10-01" \ 
--before-"2008-11-01" --no-merges -- t/ 

5610e3b - Fix testcase failure when extended attribute 

acd3b9e - Enhance hold lock file for (update,append)() 

f563754 - demonstrate breakage of detached checkout wi 

dla43f2 - reset --hard/read-tree --reset -u: remove un 

5la94af - Fix "checkout --track -b newbranch" on detac 


bOadlle - pull: allow "git pull origin $something:$cur 





























Git MHA 20,000 多 条 提交 ， 但 我 们 给 出 搜索 选项 后 ， 仅 列 出 了 其 中 满足 条 件 的 6 条 。 



































2.3.2 使 用 图 形 化 工具 查阅 提交 历史 





















































有 时候 图 形 化 工具 更 容易 展示 历史 提交 的 变化 ， 随 Git 一 同 发 布 的 gitk 就 是 这 样 
Tk 写成 的 ， 基 本 上 相当 于 git log 命令 的 可 视 化 版 本 ， 凡 是 eit log 可 以 用 的 选项 也 都 能 用 在 sitk 上 。 在 项 
作 目 录 中 输入 gitk 命令 后 ， 就 会 启动 图 2.2 所 示 的 界面 。 
EE 示 的 是 历次 提交 的 分 支 祖 先 图 谱 ， 下 半 个 窗口 显示 当前 点 选 的 提交 对 应 的 具体 差异 。 
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半 个 窗 
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2.4 撤消 操作 


任何 时 候 ， 你 都 有 可 能 需要 撤消 刚才 所 做 的 某 些 操作 。 接 下 来 ， 我 们 会 介绍 一 些 基本 的 撤消 操作 相关 的 命 
令 。 请 注意 ， 有 些 操作 并 不 总 是 可 以 撤消 的 ， 所 以 请 务必 齐 慎 小 心 ， 一 旦 失误 ， 就 有 可 能 丢失 部 分 工作 成 果 。 






























































































































































2.4.1 修改 最 后 一 次 提交 























有 时 候 我 们 提交 完了 才 发 现 漏 掉 了 几 个 文件 没有 加 ， 或 者 提交 信息 写 错 了 。 想 要 撤消 刚才 的 提交 操作 ， 可 以 


使 用 --anend 选项 重新 提交 : 
















































































$ git commit --amend 



















































































此 命令 将 使 用 当前 的 暂 存 区 域 快照 提交 。 如 果 刚才 提交 完 没 有 作 任 何 改动 ， 直 接 运 行 此 命令 的 话 ， 相 当 于 有 
重新 编辑 提交 说 明 ， 而 所 提交 的 文件 快照 和 之 前 的 一 样 。 
动 文本 编辑 器 后 ， 会 看 到 上 次 提交 时 的 说 明 ， 编 辑 它 确 认 没 问题 后 保存 退出 ， 就 会 使 用 新 的 提交 说 明 履 盖 





















































































































































刚才 提交 时 忘 了 暂 存 某 些 修改 ， 可 以 先 补 上 和 暂 存 操作 ， 然 后 再 运行 --amend 提交 : 
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Make the riumber of bytea to be read from! Jos Backus «jusfcatnook comm 
aten grigi test for current head 
dammit, thes is the second time this has reverted 
modified index ta create refs/Fweads if it is not there 
Add diff-lcs dependency 

Add dependency far Opera 

merged recent changes: 

updated the Manifest file 

fixed alternates to accept relative paths and changed 1 
added shat) def to commit object 












Merge branch "idxz" 


| merged in bryces changes ard fined some testing is 
X Clarify how to get a full count out of Repoficomm 


È m—Ó—ri——— teen cane den He 


cun holen 


Josh Goebel «dreamer 3gmad. c 
Scott Chacon «schaconé&gmail.c 
Scott Chacon cschaconfgmail.c 
Hans Engel cengel&mael.uk. tà: 
Hans Engel eengeli&erngel.uk, tà: 
Scott Chacon eschaconibgmal,c 
Scott Chacon eschaconé&gmail.c 
Scott Chacon «schacongrmail.c 
Scott Chacon «cschaconégmail.c 
Scott Chacon «sehaconigmal.c 
Scott Chacon «schaconigmail.c 
Bryce Karby «bryce&workdmedi 


Dre Parier shemen eaid 


ime  [fascianT2388rc547DOGüeRebd7blédéSfbbebd| © = am| u| 18] 
Dad (“erty eee) comma | containing: Cem) eem (eme BL ÀJ] txt WE) alt fietas Hj 


= a [Bee entium 
Agthor: Jot Backu$ «jgosSCaEnock,.com- A-F- 17:43:48 


Parent: Ë 


LL Li 


| Meere pmi n d bategi 





Committer: Scott Ohacoe eschoconfgeall.coes  2AIG-G1-389 18: 23008 
tá3iMdariichneebeidEc2zAGuEeGa Ce Ctest for current meod) 


Branch: mastar 
Felloms: Fd 
Precedes- 


Máke the number of bytei to be redd from git i stdouk configurable. 


Signed-off-Ey; eott (hacen cschaconfgeai |. com 





-ERQ11 «22,139 @ module Grit 


include Gi tRuty 


£lags «cc pelt 
- gttr acoessor igit binary. :git timeout 
+ attr de cas er igle binary, glt tisesur, 


end 


selF.dit binüry = 


$ git commit -m 'initial commit' 


$ git add forgotten file 


$ git commit --amend 


上 面 的 三 条 命令 


终 得 到 一 个 提交 ， 


UFR re dit 


图 2.2: 


2.4.2 取消 已 经 暂 存 的 文件 


接 下 来 的 两 个 小 节 将 演示 如 何 取消 暂 存 
查看 文件 状态 的 时 候 就 握 示 了 该 如 何 撤消 ， 
们 想 要 分 开 提交 ， 但 不 小 心 用 eit ada ”全 加 到 了 和 暂 存 区 域 。 该 如 何 撤消 暂 存 其 
令 的 输出 会 告诉 你 怎么 做 : 





$ git add . 
$ git status 
# On branch master 


# Changes to be committed: 


# (use "git reset HEAD <file>..." 


# 
































to unstage) 


第 二 个 提交 命 


git max size 


mul 


gitk 的 图 形 界 面 


2.4 节 撤消 操作 


2009-01-30 17:49:40 
ZUOB-08-25 04:48:51 
2008-08-25 10:55:11 
2008-08-26 10:09:45. 
2008-06-23 11:00:10 
2008-08-23 09:51:15 
2008-08-22 14:51:55 
2008-08-11 10:05:57 
2008-08-10 15:04:50 
2008-08-07 15:35:31 
2008-08-06 11:46:51 
2008-07-31 13:47:18 
2005Ó07.31 12:52:25 


Ww AC ORA 6.3707 


i 


(Pace (tree 


Comments 
be gr gure 


令 修正 了 第 一 个 的 提交 内 容 。 





















































s.f 


区 域 中 的 文件 ， 以 及 如 何 取消 工作 目录 中 已 修改 的 文件 。 不 用 担心 ， 
所 以 不 需要 死记 硬 背 。 来 看 下 面 的 例子 ， 有 两 个 修改 过 的 文件 ， 我 


中 的 一 个 文件 昵 ? git status fit 
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第 2 章 Git 基础 


# modified: | README.txt 
# modified: ^ benchmarks.rb 
# 




















H 





就 在 “Changes to be committed" 下 面 ， 括 号 











有 提示 ， 可 以 使 用 


























T 





存 。 好 吧 ， 我 们 来 试 试 取消 暂 存 benchmarks.rb 文件 : 




















$ git reset HEAD benchmarks.rb 
benchmarks.rb: locally modified 
$ git status 

# On branch master 


# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 

# 

# modified: ^ README.txt 

# 

# Changed but not updated: 

# (use "git add <file>..." to update what will be committed) 

# (use "git checkout -- <file>..." to discard changes in working directory) 
# 

# modified: ^ benchmarks.rb 

# 











这 条 命令 看 起 来 有 些 古 怪 ， 先 另 


— 





























2.4.38 取消 对 文件 的 修改 











管 ， 能 用 就 行 。 现 在 benchmarks.rb 文件 又 回 














如 果 觉 得 刚才 对 benchmarks.rb 的 修改 完全 没有 必要 ， 该 如 何 取 消 修 改 ， 回 到 之 前 的 状态 (也 就 是 
前 的 版 本 ) We? git status 同样 提示 了 具体 的 撤消 方法 ， 接 着 上 面 的 例子 ， 现 在 未 暂 存 





























T 















































# Changed but not updated: 


# (use "git add <file>..." to update what will be committed) 

# (use "git checkout -- <file>..." to discard changes in working directory) 
# 

# modified: benchmarks.rb 

# 






























































你 还 在 用 老 版 本 ， 我 们 强烈 建议 你 升级 ， 以 获取 最 佳 的 用 户 体验 ) ， 让 我 们 试 试看 : 























$ git checkout -- benchmarks.rb 

$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 
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git reset HEAD <file> 














o 的 方式 取消 暂 
































DR 





到 了 之 前 已 修改 未 暂 存 的 状 


修改 之 
区 域 看 起 来 像 这 样 : 




















在 第 二 个 括号 中 ， 我 们 看 到 了 抛弃 文件 修改 的 命令 (至少 在 Git 1.6.1 以 及 更 高 版 本 














羊 提示 ， 如 

















Scott Chacon Pro Git 


# modified: | README.txt 











可 以 看 到 ， 该 文件 已 经 恢复 到 修改 前 的 版 本 。 你 可 能 已 经 意 MAS 


























2.5% 远程 仓库 的 使 用 
































= 

















都 没有 了 ， 因 为 我 们 刚刚 把 之 前 版 本 的 文件 复制 过 来 重 写 












































Y 




































































需要 保留 刚才 的 修改 。 如 果 只 是 想 回 退 版 本 ， 同 时 保留 



































stashing 和 分 支 来 处 至 


Liz 


EE， 应 该 会 更 好 些 。 





才 的 修改 以 便 将 3 














记 住 ， 


TE 
—~ 
Ly 
T 
a 
wu 
q 


























提交 到 Git 的 都 可 以 被 恢复 。 即 便 在 已 经 删除 的 分 支 中 的 提交 
































的 提交 ， 都 可 以 被 恢复 (关于 数据 恢复 的 内 容 见 第 九 章 ) 
对 Git 来 说 它们 就 像 从 未 存在 过 一 样 。 




















2.5 远程 仓库 的 使 用 














k —1 仅 限 于 没 











































































































， 或 者 用 --amend 
































AT 各 































































































































































































要 参与 任何 一 个 Git 项 目的 协作 ， 必 须要 了 解 该 如 何 管 
库 ， 可 能 会 有 好 多 个 ， 有 些 你 只 能 读 ， 另 外 有 些 可 以 写 
仓库 ， 以 便 推送 或 拉 取 数据 ， 分 享 各 自 的 工作 进展 。 管 理 i 
奈 ， 管 理 各 式 远 程 库 分 支 ， 定 义 是 否 跟踪 这 些 分 支 ， 等 等 。 


2.5.1 查看 当前 的 远程 库 

















要 查看 当前 配置 有 哪些 远程 仓库 ， 可 以 用 git remote mex. 
项 目 后 ， 至 少 可 以 看 到 一 个 名 为 origin 的 远程 库 ，Git $ 






















































































$ git clone git://github.com/schacon/ticgit.git 

Initialized empty Git repository in /private/tmp/ticgit/.git/ 
remote: Counting objects: 595, done. 

remote: Compressing objects: 100% (269/269), done. 

remote: Total 595 (delta 255), reused 589 (delta 253) 
Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done. 
Resolving deltas: 100% (255/255), done. 

$ cd ticgit 

$ git remote 


origin 



























































手 个 远程 库 的 简短 名 字 。 








TEE EE SE 






























































标识 你 所 克隆 的 原始 仓库 : 





























也 可 以 加 上 -v 选项 〈 译 注 ， 此 为 一 verbose 的 简写 ， 





$ git remote -v 


origin git://github.com/schacon/ticgit.git 

















如 果 有 多 个 远程 仓库 ， 此 命令 将 全 部 列 出 。 比 如 在 我 的 Grit 项 目 


























$ cd grit 


$ git remote -v 


， 显 示 对 应 的 克隆 地 址 : 
























































y => 
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$23 cit 基础 


bakkdoor git://github.com/bakkdoor/grit.git 
cho45 git://github.com/cho45/grit.git 
defunkt — git://github.com/defunkt/grit.git 
koke git://github.com/koke/grit.git 
origin git@github.com:mojombo/grit.git 


HER, Feat BY PAESE ERA Wk LE 






































户 的 仓库 中 ， 拉 取 
有 这 个 仓库 我 能 推 





Scott Chacon Pro Git 





也 们 的 提交 到 
送 数据 上 去 









































本 地 。 请 注意 ， 上 面 列 出 的 地 址 只 
(我 们 会 在 第 四 章 解 释 原 因 ) 。 






































有 origin 用 的 是 SSH URL 链接 ， 所 以 也 只 
2.5.2 添加 远程 仓库 
要 添加 一 个 新 的 远程 仓库 ， 可 以 指定 一 个 简单 的 名 5 

















$ git remote 

origin 

$ git remote add pb git://github.com/paulboone/ticgit.git 
$ git remote -v 

origin git://github.com/schacon/ticgit.git 

pb git://github.com/paulboone/ticgit.git 





H 
F1 








Tn 








现在 可 以 


以 运行 git fetch pb: 














du 


$ git fetch pb 
remote: Counting objects: 58, done. 

remote: Compressing objects: 100% (41/41), done. 
remote: Total 44 (delta 24), reused 1 (delta 0) 
Unpacking objects: 100% (44/44), done. 

From git://github.com/paulboone/ticgit 

master 


* [new branch] -> pb/master 


* [new branch] ticgit -> pb/ticgit 

















, Paul 的 主干 分 支 (master) 已 








im 











pb 指 代 对 应 的 仓库 地 址 了 。 比 如 说 


完全 可 以 在 本 





， 以 便 将 来 引用 ，i 


， 要 抓 取 所 























Es 








Paul 




















4 
JE 们 git remote add [shortname] [url]: 


























有 的 ， 









































到 自己 的 某 个 分 支 ， 或 者 切换 到 这 个 分 























JERE) ET ° 






































2.5.3 从 远程 仓库 抓 取 数据 
正如 之 前 所 看 到 的 ， 可 以 下 的 
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HH 




















ib 























$ git fetch [remote-name | 

















命令 会 到 远程 仓库 








还 没 

















有 你 














此 命令 会 y BUS 
的 所 有 分 文 ， 将 其 中 某 个 分 文 
关于 分 支 的 概念 和 操作 。) 
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E 
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令 从 远程 仓库 抓 取 数据 到 本 地 : 














有 的 数据 。 运 行 完 成 后 ， 你 就 可 以 在 
条 只 是 取出 某 个 分 文 ， 一 探 























但 本 地 仓库 没有 的 信息 ， 


可 





访问 了 ， 对 应 的 名 字 是 pb/master， 你 可 以 将 它 


ZM 
(m 

















仓库 








地 访问 该 远 





F cx 

















(我 们 会 用 


Tubb ? 


E 第 三 章 详 


讨论 























Scott Chacon Pro Git 2.57 远程 仓库 的 使 用 

















如 果 是 克隆 了 一 个 仓库 ， 此 命令 会 自动 将 远程 仓库 归于 origin 名 下 。 所 以 ，git fetch origin 会 抓 取 从 你 上 

次 克隆 以 来 别人 上 传 到 此 远程 仓库 中 的 所 有 更 新 (或 是 上 次 fetch 以 来 别人 提交 的 更 新 ) 。 有 一 点 很 重要 ， 
需要 记 住 ，fetch 命令 只 是 将 远 端的 数据 拉 到 本 地 仓库 ， 并 不 自动 合并 到 当前 工作 分 支 ， 只 有 当 你 确实 准备 好 
了 ， 才 能 手工 合并 。 
如 果 设 置 了 某 个 分 支 用 于 跟踪 某 个 远 端 仓 库 的 分 支 (参见 下 节 及 第 三 章 的 内 容 ) ， 可 以 使 用 eit pull 命令 
自动 抓 取 数 据 下 来 ， 然 后 将 远 端 分 支 自 动 合 并 到 本 地 仓库 中 当前 分 支 。 在 日 常 工 作 中 我 们 经 常 这 么 用 ， 既 快 
HE o RRE, UIEIL F sit clone 命令 本 质 上 就 是 自动 创建 了 本 地 的 master 分 支 用 于 跟 踩 远程 仓库 中 的 
aster 分 支 (假设 远程 仓库 确实 有 master 分 文 ) 。 所 以 一 般 我 们 运行 sit pull， 目 的 都 是 要 从 原始 克隆 的 远 
端 仓 库 中 抓 取 数 据 后 ， 合 并 到 工作 目录 中 当前 分 支 。 
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2.5.4 推送 数据 到 远程 仓库 


项 目 进行 到 一 个 阶段 ， 要 同 别人 分 享 目前 的 成 果 ， 可 以 将 本 地 仓库 中 的 数据 推送 到 远程 仓库 。 实 现 这 个 任务 
的 命令 很 简单 : git push [remote-name] [branch-name] ? 如 果 要 把 本 地 的 master 分 支 推送 到 origin 服务 器 上 (再 
次 说 明 下 ， 克 隆 操 作 会 自动 使 用 默认 的 master 和 origin 名 字 ) ， 可 以 运行 下 面 的 命令 : 


















































































































































$ git push origin master 





































































































































































































在 所 克隆 的 服务 器 上 有 写 权 限 ， 或 者 同一 时 刻 没有 其 他 人 在 推 数据 ， 这 条 命令 才 会 如 期 完成 任务 。 如 果 
在 你 推 数据 前 ， 已 经 有 其 他 人 推送 了 若干 更 新 ， 那 你 的 推送 操作 就 会 被 驳回 。 你 必须 先 把 他 们 的 更 新 抓 取 到 本 
地 ， 并 到 自己 的 项 目 中 ， 然 后 才 可 以 再 次 推送 。 有 关 推 送 数据 到 远程 仓库 的 详细 内 容 见 第 三 章 。 




















































































































2.5.5 查看 远程 仓库 信息 






































我 们 可 以 通过 命令 git remote show [remote-name] 查看 某 个 远程 仓库 的 详细 信息 ， 比 如 要 看 所 克隆 的 origin 仓 
库 ， 可 以 运行 : 









































$ git remote show origin 
* remote origin 
URL: git://github.com/schacon/ticgit.git 
Remote branch merged with 'git pull' while on branch master 
master 
Tracked remote branches 
master 


ticgit 



























































除了 对 应 的 克隆 地 址 外 ， 它 还 给 出 了 许多 额外 的 信息 。 它 友善 地 告诉 你 如 果 是 在 master 分 文 ， 就 可 以 用 
sit pull 命令 抓 取 数 据 合 al 本 地 。 另外 还 列 出 了 所 有 处 于 跟踪 状态 中 的 远 端 分 文 。 
实际 使 用 过 程 中 ，git remote show 给 出 的 信息 可 能 会 像 这 样 : 




























































































$ git remote show origin 
* remote origin 

URL: git@github.com:defunkt/github.git 

Remote branch merged with 'git pull' while on branch issues 


issues 
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$23 Git 基础 Scott Chacon Pro Git 





Remote branch merged with 'git pull' while on branch master 
master 
New remote branches (next fetch will store in remotes/origin) 
caching 
Stale tracking branches (use 'git remote prune') 
libwalker 
walker2 
Tracked remote branches 
acl 
apiv2 
dashboard2 
issues 
master 
postgres 
Local branch pushed with 'git push' 


master:master 




















告诉 我 们 ， 运 行 sit push 时 缺 省 推送 的 分 文 是 什么 〈 译 注 : 最 后 两 行 ) 。 它 还 显示 了 有 哪些 远 端 分 支 还 
没有 同步 到 本 地 (译注 ， 第 六 行 的 caching 分 文 ) ， 哪 些 已 同步 到 本 地 的 远 端 分 支 在 远 端 服务 器 上 已 被 删除 


(译注 : Stale tracking branches 下 面 的 两 个 分 文 ) ， 以 及 运行 git pui 时 将 自动 合并 哪些 分 文 (译注 :前 
四 行 中 列 出 的 issues 和 master 分 支 ) © 








n 
























































































































































2.5.6 远程 仓库 的 删除 和 重 命名 


在 新 版 Git 中 可 以 用 sit remote rename 命令 修改 某 个 远程 仓库 的 简短 名 称 ， 比 如 想 把 pb 改 成 paul， 可 以 这 
么 运行 : 





















































$ git remote rename pb paul 
$ git remote 
origin 


paul 











注意 ， 对 远程 仓库 的 重 命 名 ， 也 会 使 对 应 的 分 支 名 称 发 生变 化 ， 原 来 的 pb/master 分 支 现在 成 了 paul/master ° 
磁 到 远 端 仓库 服务 器 迁移 ， 或 者 原来 的 克隆 镜像 不 再 使 用 ， 又 或 者 某 个 参与 者 不 再 页 献 代 码 ， 那 么 需要 移 除 
对 应 的 远 端 仓库 ， n] 以 运行 git remote rm 命令 : 















































































































































$ git remote rm paul 
$ git remote 


origin 


2.6 打 标 签 





























Eee VCS = Git 也 可 以 对 某 一 时 间 点 上 的 版 本 打上 标签 。 人 们 在 发 布 某 个 软件 版 本 (比如 v1.0 
) 的 时 候 ， 经 常 这 么 做 。 本 市 我 们 一 起 来 学 习 如 何 列 出 所 有 可 用 的 标签 ， 如 何 新 建 标 签 ， 以 及 各 种 不 同类 
m 之 间 的 差别 。 
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Scott Chacon Pro Git 2.6% 打 标 签 


2.6.1 列 显 已 有 的 标签 

















列 出 现 有 标签 的 命令 非常 简单 ， 直 接 运行 sit tas 即 可 : 




















$ git tag 
v0.1 
v1.3 


























显示 的 标签 按 字母 顺序 排列 ， 所 以 标签 的 先后 并 不 表示 重要 程度 的 轻重 。 
我 们 可 以 用 特定 的 搜索 模式 列 出 符合 条 件 的 标签 。 在 Git 自身 项 目 仓库 中 ， 有 着 超过 240 个 标签 ， 如 果 你 
只 对 1.4.2 系列 的 版 本 感 兴 趣 ， 可 以 运行 下 





























































































































条 的 命令 : 








S-eit tag l vl 
TRATZ 
TATZ 
le 
al 2. 


2.6.2 新 建 标签 


Git 使 用 的 标签 有 两 种 类 型 ， 轻 量 级 的 (lightweight) 和 含 附 注 的 (annotated) 。 轻 量 级 标签 就 像 是 个 不 
会 变化 的 分 支 ， 实 际 上 它 就 是 个 指向 特定 提交 对 象 的 引用 。 而 含 附注 标签 ， 实 际 上 是 存储 在 仓库 中 的 一 个 独立 
对 象 ， 它 有 自身 的 校 验 和 信息 ， 包 含 着 标签 的 名 字 ， 电 子 邮 件 地 址 和 日 期 ， 以 及 标签 说 明 ， 标 签 本 身 也 允许 使 
J GNU Privacy Guard (GPG) 来 签署 或 验证 。 一 般 我 们 都 建议 使 用 舍 附 注 型 的 标签 ， 以 便 保留 相关 信息 ; 当 
然 ， 如 果 只 是 临时 性 加 注 标签 ， 或 者 不 需要 旁 注 额外 信息 ， 用 轻 量 级 标签 也 没 问题 。 














































































































































































































































































































































































































2.6.3 含 附 注 的 标签 


创建 一 个 含 附注 类 型 的 标签 非常 简单 ， 用 -a。 (译注 取 annotated 的 首 字母 ) 指定 标签 名 字 即 可 : 




































































$ git tag -a vl.4 -m ‘my version 1.4' 
$ git tag 















































LU 
N 
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而 -m 选项 则 指定 了 对 应 的 标签 说 明 ，Git 会 将 此 说 明 一 同 保存 在 标签 对 象 中 。 如 果 在 此 选项 后 没有 给 
体 的 说 明 内 容 ，Git 会 启动 文本 编辑 软件 供 你 输入 。 
可 以 使 用 git show 命令 查看 相应 标签 的 版 本 信息 ， 
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EE 示 打 标 签 时 的 提交 对 象 。 











hi 
uj 
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$ git show v1.4 
tag vl.4 
Tagger: Scott Chacon «schaconegee-mail.com- 


Date: Mon Feb 9 14:45:11 2009 -0800 
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$23 Git 基础 Scott Chacon Pro Git 





my version 1.4 

commit 15027957951b64cf874c3557a0f 3547bd83b3ff6 
Merge: 4a447f£7... a6b4c97... 

Author: Scott Chacon <schacon@gee-mail.com> 


Date: Sun Feb 8 19:02:46 2009 -0800 


Merge branch ‘experiment’ 











我 们 可 以 看 到 在 提交 对 象 信息 上 面 ， 列 出 了 此 标签 的 提交 者 和 提交 时 间 ， 以 及 相应 的 标签 说 明 。 









































2.6.4 签署 标签 


















































如 果 你 有 自己 的 私 钥 ， 还 可 以 用 GPG 来 签署 标签 ， 只 需要 把 之 前 的 -a 改 为 -s (译注 : W Signed 的 
字母 ) 即 可 : 
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$ git tag -s v1.5 -m 'my signed 1.5 tag' 
You need a passphrase to unlock the secret key for 
user: "Scott Chacon <schacon@gee-mail.com>" 


1024-bit DSA key, ID F721C45A, created 2009-02-09 


























现在 再 运行 git show 会 看 到 对 应 的 GPG 签名 也 附 在 其 内 : 


























$ git show v1.5 
tag vl.5 
Tagger: Scott Chacon <schacon@gee-mail.com> 


Date: Mon Feb 9 15:22:20 2009 -0800 

my signed 1.5 tag 

Version: GnuPG v1.4.8 (Darwin) 

iEYEABECAAYFAkmQur IACgkQON3DxfchxFr5cACeIMN*ZxLKggJQfOQY i QBwgySN 
Ki0An2JeAVUCAiJ70x6ZEtK+NvZA§82/ 

=WryJ 

commit 15027957951b64cf874c3557a0f3547bd83b3ff6 

Merge: 4a447f7... a6b4c97... 


Author: Scott Chacon <schacon@gee-mail.com> 


Date: Sun Feb 8 19:02:46 2009 -0800 


Merge branch 'experiment' 

















稍 后 我 们 再 学 习 如 何 验证 已 经 签署 的 标签 。 





























2.6.5 轻 量 级 标签 


轻 量 级 标签 实际 上 就 是 一 个 保存 着 对 应 提交 对 象 的 校 验 和 信息 的 文件 。 要 创建 这 样 的 标签 ， 一 个 -a，-s 或 
-m 选项 都 不 用 ， 直 接 给 出 标签 名 字 即 可 : 



































fm 



























































Scott Chacon Pro Git 2.690 打 标 签 


$ git tag vl.4-lw 
$ git tag 

v0.1 

v1.3 

v1.4 

vl.4-1w 

x1.5 



























































现在 运行 sit show 查看 此 标签 信息 ， 就 只 有 相应 的 提交 对 象 摘要 : 











$ git show v1.4-1w 

commit 15027957951b64cf874c3557a0f 3547 bd83b3ff6 
Merge: 4a447f£7... a6b4c97... 

Author: Scott Chacon <schacon@gee-mail.com> 


Date: | Sun Feb 8 19:02:46 2009 -0800 


Merge branch 'experiment' 


2.6.6 验证 标签 


可 以 使 用 git tag -v [tag-name] (译注 HX verify 的 首 字 母 ) 的 方式 验证 已 经 签署 的 标签 。 此 命令 会 调用 
GPG 来 验证 签名 ， 所 以 你 需要 有 签署 者 的 公 钥 ， 存 放 在 keyring 中 ， 才 能 验证 : 
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$ git tag -v v1.4.2.1 

object 883653babd8ee7ea23e6a5c392bb739348bleb61 

type commit 

tag vl.4.2.1 

tagger Junio C Hamano <junkio@cox.net> 1158138501 -0700 


GIT 1.4.2.1 


Minor fixes since 1.4.2, including git-mv and git-http with alternates. 
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A 
gpg: Good signature from "Junio C Hamano <junkio@cox.net>" 

gpg: aka "[jpeg image of size 1513]" 

Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D COC6 D9A4 F311 9B9A 











H 
































若是 没有 签署 者 的 公 钥 ， 会 报告 类 似 下 面 这 样 的 错误 : 

















gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A 
gpg: Can't check signature: public key not found 
error: could not verify the tag 'vl.4.2.1' 


2.6.7 后 期 加 注 标签 


你 甚至 可 以 在 后 期 对 早先 的 某 次 提交 加 注 标签 。 比 如 在 下 面 展 示 的 提交 历史 
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基础 





$ git log --pretty-oneline 

15027957951b64cf874c3557a0f3547bd83b3f £6 
a6b4c97498bd301d84096da251c98a07c7723e65 
0d52aaab4479697da7686c15£77a3d64d9165190 
6d52a27 1eda8725415634dd79daabbc4d9b6008e 
0b7434d86859cc7b8c3d5eldddfed66f£742fcbe 
4682c3261057305bdd616e23b64b0857d832627b 
166ac0c4d3£420721lacbb115cc33848dfcc2121a 
9fceb02d0ae598e95dc970b74767f19372d61af8 
964f16d36dfccde844893cac5b347e7b3d44abbc 
8abcbc430f1a9c3d00faaeffd07798508422908a 





dil Vs T EGE 


"updated rakefile" 


Merge branch 'experiment' 
beginning write support 
one more thing 

Merge branch 'experiment' 
added a commit function 
added a todo file 
started write support 
updated rakefile 

commit the todo 


updated readme 


后 为 此 项 目 























签 的 时 候 跟 上 对 应 提交 对 象 的 校 验 和 


$ git tag -a v1.2 9fceb02 





可 以 看 到 我 们 已 经 补 上 了 标签 : 








.A-1w 


$ git show v1.2 
tag v1.2 








(或 前 几 位 字符 ) 即 可 : 


Tagger: Scott Chacon <schacon@gee-mail.com> 


Date: Mon Feb 9 15:32:16 2009 -0800 


version 1.2 


commit 9fceb02d0ae598e95dc970b74767f19372d61af8 


Author: Magnus Chacon <mchacon@gee-mail.com> 


Date: Sun Apr 27 20:43:35 2008 -0700 


updated rakefile 


NF l ^ 
分 至 标签 


2.6.8 























默认 情况 下 ，git push 








不 会 把 标签 传送 到 远 端 服务 器 上 ， 只 有 通过 





打上 版 本 号 v1.2, 


没关系 ， 现 在 也 能 做 。 


Scott Chacon Pro Git 


= 


ZN 





要 在 打 标 









































命令 格式 如 同 推送 分 支 ， 运行 git push origin [tagname] 即 可 : 





$ git push origin v1.5 
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分 享 标签 到 远 端 仓库 。 


Scott Chacon Pro Git 2.78 FUME 


Counting objects: 50, done. 

Compressing objects: 100% (38/38), done. 
Writing objects: 100% (44/44), 4.56 KiB, done. 
Total 44 (delta 18), reused 8 (delta 1) 

To git@github.com:schacon/simplegit. git 

* [new tag | Wis - wil. 5 
























































如 果 要 一 次 推送 所 有 (本 地 新 增 的 ) 标签 上 去 ， 可 以 使 用 --tags 选项 : 








$ git push origin --tags 

Counting objects: 50, done. 

Compressing objects: 100% (38/38), done. 
Writing objects: 100% (44/44), 4.56 KiB, done. 
Total 44 (delta 18), reused 8 (delta 1) 

To git@github.com:schacon/simplegit.git 


* [new tag] v0.1 -> v0.1 
* [new tag | ilo == vallum 
* [new tag] wll 4h — yl 4 
* [new tag | vl.4-1w -> vl.4-lw 
* [new tag | VIR SS ale) 


























现在 ， 其 他 人 克隆 共享 仓库 或 拉 取 数据 同步 后 ， 也 会 看 到 这 些 标签 。 






































2.7 技巧 和 窍门 









































在 结束 本 章 之 前 ， 我 还 想 和 大 家 分 享 一 些 Git 使 用 的 技巧 和 和 窍门。 很 多 使 用 Git 的 开发 者 可 能 根本 就 没 用 
过 这 些 技巧 ， 我 们 也 不 是 说 在 读 过 本 书后 非得 用 这 些 技巧 不 可 ， 但 至 少 应 该 有 所 了 解 吧 。 说 实话 ， 有 了 这 些小 
窍门 ， 我 们 的 工作 可 以 变 得 更 简单 ， 更 轻松 ， 更 高 效 。 

































































































































































" 





2.7.1 自动 完成 





























如 果 你 用 的 是 Bash shell， 可 以 试 试看 Git 提供 的 自动 完成 脚本 。 下 载 Git 的 源 代码 ， 进 入 contriv/ 
completion 目录， 会 看 到 一 个 git-completion.bash 文件 。 将 此 文件 复制 到 你 自己 的 用 户主 目录 中 (译注 : 按照 下 
面 的 示例 ， 还 应 改名 加 上 点 : cp git-completion.bash ~/.git-completion.bash) , 把 下 面 一 行内 容 添 加 
到 你 的 .bashrc 文件 中 : 

































































































































































source ^/.git-completion.bash 



































也 可 以 为 系统 上 所 有 用 户 都 设置 默认 使 用 此 脚本 。Mac 上 将 此 脚本 复制 到 /opt/1ocal/etc/bash_completion.d 
KP, Linux 上 则 复制 到 /etc/bash completion.a/ 目录 中 即 可 。 这 两 处 目录 中 的 脚本 ， 都 会 在 Bash 启动 时 自动 



































































































































































































































如 果 在 Windows 上 安装 了 msysGit， 默 认 使 用 的 Git Bash 就 已 经 配 好 了 这 个 自动 完成 脚本 ， 可 以 直接 使 







































































在 输入 Git 命令 的 时 候 可 以 敲 两 次 跳 格 键 (Tao) ， 就 会 看 到 列 出 所 有 匹配 的 可 用 命令 建议 : 
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$23: Git 基础 Scott Chacon Pro Git 


$ git co<tab><tab> 


commit config 



























































此 例 中 ， 键 入 git co 然后 连 按 两 次 Tab 键 ， 会 看 到 两 个 相关 的 建议 (命令 ) commit 和 config。 继 而 输 
入 m<tab> 会 自动 完成 git commit 命令 的 输入 

命令 的 选项 也 可 以 用 这 种 方式 自动 完成 ， 其 实 这 种 情况 更 实用 些 。 比 如 运行 sit log 的 时 候 筷 了 相关 选项 的 
名 字 ， 可 以 输入 开头 的 几 个 字母 ， 然 后 敲 Tab 键 看 看 有 哪些 匹配 的 : 
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$ git log --s<tab> 


--shortstat  --since-  --src-prefix-  --stat --summary 








这 个 技巧 不 错 吧 ， 可 以 市 省 很 多 输入 和 查阅 文档 的 时 间 。 























2.7.2 Git 命令 别名 























Git 并 不 会 推断 你 输入 的 几 个 字符 将 会 是 哪 条 命令 ,不 过 如 果 想 偷懒 ， 少 敲 几 个 命令 的 字符 ， 可 以 用 git 
config 为 命令 设置 别名 9 KBE FE 的 例子 : 















































$ git config --global alias.co checkout 
$ git config --global alias.br branch 
$ git config --global alias.ci commit 


$ git config --global alias.st status 



































现在 ， 如 果 要 输入 git commit 只 需 键 入 git ci 即 可 。 而 随 着 Git 使 的 深入 ， 会 有 很 多 经 党 要 用 到 的 命 
令 ， 遇 到 这 种 情况 ， 不 妨 建 个 别名 提高 效率 。 
使 用 这 种 技术 还 可 以 创造 出 新 的 命令 ， 比 方 说 取消 暂 存 文件 时 的 输入 比较 楷 琐 ， 可 以 自己 设置 一 下 : 



























































































































































$ git config --global alias.unstage 'reset HEAD --' 














这 样 一 来 ， 下 面 的 两 条 命令 完全 等 同 : 








$ git unstage fileA 
$ git reset HEAD fileA 











En 
x 
ux 

















使 用 别名 的 方式 看 起 来 更 清楚 。 刀 外 ， 我 们 还 经 常设 置 last 命令 : 
























































$ git config --global alias.last 'log -1 HEAD' 





























然后 要 看 最 后 一 次 的 提交 信息 ， 就 变 得 简单 多 了 : 


























Scott Chacon Pro Git 


$ git last 
commit 66938dae3329c7aebe598c2246a8e6af90d04646 
Author: Josh Goebel <dreamer3@example.com> 


Date: Tue Aug 26 19:48:51 2008 +0800 


test for current head 


Signed-off-by: Scott Chacon <schacon@example.com> 












































可 以 看 出 ， 实 际 上 Git 只 是 简单 地 在 命令 中 替换 了 你 设置 的 别名 。 不 过 有 了 时 候 我 们 希望 运行 某 个 外 部 命 
令 ， 而 非 Git 的 附属 工具 ， 这 个 好 办 ， 只 需要 在 命令 前 加 上 ! 就 行 。 如 果 你 自己 写 了 些 处 理 Git 仓库 信息 


LN 


的 脚本 的 话 ， 就 可 以 用 这 种 技术 包装 起 来 。 作 为 演示 ， 我 们 可 以 设置 用 sit visual 启动 gitk: 


























































































































































































































$ git config --global alias.visual "!gitk" 
























































到 目前 为 止 ， 你 已 经 学 会 了 最 基本 的 Git 操作 : 创建 和 克隆 仓库 ， 作 出 更 新 ， 暂 存 并 提交 这 些 更 新 ， 以 及 
看 所 有 历史 更 新 记录 。 接 下 来 ， 我 们 将 学 习 Git 的 必 杀 技 特性 .分支 模 型 。 
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几乎 每 一 种 版 本 控制 系统 都 以 某 种 形式 支持 分 文 。 使 用 分 支 意味 着 你 可 以 从 开发 主线 上 分 离开 来 ， 然 后 在 不 
影响 主线 的 同时 继续 工作 。 在 很 多 版 本 控制 系统 中 ， 这 是 个 昂贵 的 过 程 ， 常 常 需要 创建 一 个 源 代码 目录 的 完整 
副本 ， 对 大 型 项 目 来 说 会 花费 很 长 时 间 。 

有 人 把 Git 的 分 支 模型 称 为 “ 必 杀 技 特性 ”， 而 正 是 因为 它 ， 将 Git 从 版 本 控制 系统 家 族 里 区 分 出 来 。Git 
有 何 特 别 之 处 呢 ?Git 的 分 支 可 谓 是 难以 置信 的 轻 量 级 ， 它 的 新 建 操作 几乎 可 以 在 瞬间 完成 ， 并 且 在 不 同 分 文 
切换 起 来 也 差不多 一 样 快 。 和 许多 其 他 版 本 控制 系统 不 同 ，Git 鼓励 在 工作 流程 中 频繁 使 用 分 支 与 合并 ， 哪 
天 之 内 进行 许多 次 都 没有 关系 。 理 解 分 文 的 概念 并 熟练 运用 后 ， 你 才 会 意识 到 为 什么 Git 是 一 个 如 此 强 
大 而 独特 的 工具 ， 并 从 此 真正 改变 你 的 开发 方式 。 
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3.1 何谓 分 支 











为 了 理解 Git 分 支 的 实现 方式 ， 我 们 需要 回顾 一 下 Git 是 如 何 储存 数据 的 。 或 许 你 还 记得 第 一 章 的 内 
A, Git 保存 的 不 是 文件 差异 或 者 变化 量 ， 而 只 是 一 系列 文件 快照 。 
在 Git 中 提交 时 ， 会 保存 一 个 提交 (commit) 对 象 ， 它 包含 一 个 指向 暂 存 内 容 快照 的 指针 ， 作 者 和 相关 附 
届 信 息 ， 以 及 一 定数 量 (也 可 能 没有 ) 指向 该 提交 对 象 直接 祖先 的 指针 : 第 一 次 提交 是 没有 直接 祖先 的 ， 普 通 
提交 有 一 个 祖先 ， 由 两 个 或 多 个 分 支 合 并 产生 的 提交 则 有 多 个 祖先 。 
为 直观 起 见 ， 我 们 假设 在 工作 目录 中 有 三 个 文件 ， 准 备 将 它们 和 暂 存 后 提交 。 和 暂 存 操作 会 对 每 一 个 文件 计算 
校 验 和 ( 即 第 一 章 中 提 到 的 SHA-1 RAFE) ， 然 后 把 当前 版 本 的 文件 快照 保存 到 Git 仓库 中 (cit 使 用 
blob 类 型 的 对 象 存储 这 些 快 照 ) ， 并 将 校 验 和 加 入 暂 存 区 域 : 






































































































































































































































































































































































































































$ git add README test.rb LICENSE2 


$ git commit -m 'initial commit of my project' 
































当 使 用 sit commit 新 建 一 个 提交 对 象 前 ，Git 会 先 计 算 每 一 个 子 目录 (本 例 中 就 是 项 目 根 目录 ) 的 校 验 和 ， 
然后 在 Git 仓库 中 将 这 些 目录 保存 为 树 (tree) 对 象 。 之 后 Git 创建 的 提交 对 象 ， 除 了 包含 相关 提交 信息 以 
外 ， 还 包含 着 指向 这 个 树 对 象 (项目 根 目录 ) 的 指针 ， 如 此 它 就 可 以 在 将 来 需要 的 时 候 ， 重 现 此 次 快照 的 内 容 
了 。 

ME, Git 仓库 中 有 五 个 对 象 : 三 个 表示 文件 快照 内 容 的 blob 对 象 ; 一 个 记录 着 目录 树 内 容 及 其 中 各 个 文 
件 对 应 blob 对 象 索引 的 tree 对 象 ， 以 及 一 个 包含 指向 tree MR MAR) 的 索引 和 其 他 提交 信息 元 数据 
的 commit 对 象 。 概 念 上 来 说 ， 仓 库 中 的 各 个 对 象 保 存 的 数据 和 相互 关系 看 起 来 如 图 3.1 所 示 : 

作 些 修改 后 再 次 提交 ， 那 么 这 次 的 提交 对 象 会 包含 一 个 指向 上 次 提交 对 象 的 指针 (译注 ， 即 下 图 中 的 
parent 对 象 ) 。 两 次 提交 后 ， 仓 库 历 史 会 变 成 图 3.2 的 样子 : 
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图 3.1: 一 次 提交 后 仓库 里 的 数据 


98ca9.. 34ac2.. f30ab.. 





图 3.2: 多 次 提交 后 的 Git 对 象 数 据 





MERKI ° Git 中 的 分 支 ， 其 实 本 质 上 仅仅 是 个 指向 commit 对 象 的 可 变 指针 。Git 会 使 用 master 作 
为 分 支 的 默认 名 字 。 在 若干 次 提交 后 ， 你 其 实 已 经 有 了 一 个 指向 最 后 一 次 提交 对 象 的 master 分 支 ， 它 在 每 次 


提交 的 时 候 都 会 自动 向 前 移动 。 



































图 3.3: 指向 提交 数据 历史 的 分 支 





IA, Git 又 是 如 何 创建 一 个 新 的 分 文 的 呢 ? 答案 很 简单 ， 创 建 一 个 新 的 分 支 指针 。 比 如 新 建 一 个 testing 
分 支 ， 可 以 使 用 git branch 命令 : 


$ git branch testing 


这 会 在 当前 commit 对 象 上 新 建 一 个 分 支 指针 ( 见 图 3.4) 
那么 ，Git 是 如 何 知道 你 当前 在 哪个 分 支 上 工作 的 呢 ? 其 实 答案 也 很 简单 ， 它 保存 着 一 个 名 为 HEAD 的 特别 
指针 。 请 注意 它 和 你 熟知 的 许多 其 他 版 本 控制 系统 (比如 Subversion 或 CVS) 里 的 HEAD 概念 大 不 相同 。 在 
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图 3.4: 多 个 分 支 指 向 提交 数据 的 历史 








Git 中 ， 它 是 一 个 指向 你 正在 工作 中 的 本 地 分 支 的 指针 。 运 行 git branch 命令 ， 仅 仅 是 建立 了 一 个 新 的 分 文 ， 
但 不 会 自动 切换 到 这 个 分 支 中 去 ， 所 以 在 这 个 例子 中 ， 我 们 依然 还 在 master PRET (参考 图 3.5) 


LH 


| 98009 | Ea Ea 


图 3.5: HEAD 指向 当前 所 在 的 分 支 













































































要 切换 到 其 他 分 支 ， 可 以 执行 eit checkout 命令 。 我 们 现在 转换 到 新 建 的 testing 分 支 : 





$ git checkout testing 





这 样 HEAD 就 指向 了 testing 分 支 ( 见 图 3-6) 。 


图 3.6: HEAD 在 你 转换 分 支 时 指向 新 的 分 支 




















这 样 的 实现 方式 会 给 我 们 带 来 什么 好 处 呢 ? 好 吧 ， 现 在 不 妨 再 提交 一 次 : 
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$ vim test.rb 


$ git commit -a -m 'made a change' 





图 3.7 展示 了 提交 后 的 结果 。 
fea 
Eu 


HEAD 








E 3.7: 每 次 提交 后 HEAD 随 着 分 支 一 起 向 前 移动 





非常 有 趣 ， 现 在 testing 分 文 向 前 移动 了 一 格 ， 而 master 分 支 仍然 指向 原先 git checkout 时 所 在 的 commit 
对 象 。 现 在 我 们 回 到 master 分 支 看 看 : 


























$ git checkout master 











图 3.8 显示 了 结果 。 


HEAD 


E 


图 3.8: HEAD 在 一 次 checkout 之 后 移动 到 了 另 一 个 分 支 











这 条 命令 做 了 两 件 事 。 它 把 HEAD 指针 移 回 到 master 分 支 ， 并 把 工作 目录 中 的 文件 换 成 了 master 分 文 
所 指向 的 快照 内 容 。 也 就 是 说 ， 现 在 开始 所 做 的 改动 ， 将 始 于 本 项 目 中 一 个 较 老 的 版 本 。 它 的 主要 作用 是 将 
testing 分 文 里 作出 的 修改 暂时 取消 ， 这 样 你 就 可 以 向 另 一 个 方向 进行 开发 。 

我 们 作 些 修改 后 再 次 提交 : 


































































































$ vim test.rb 


$ git commit -a -m 'made other changes 
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现在 我 们 的 项 目 提交 历史 产生 了 分 义 (如 图 3.9 所 示 ) ， 因 为 刚才 我 们 创建 了 一 个 分 支 ， 转 换 到 其 中 进行 
了 一 些 工 作 ， 然 后 又 回 到 原来 的 主 分 支 进 行 了 另外 一 些 工作 。 这 些 改变 分 别 孤立 在 不 同 的 分 支 里 :我 们 可 以 在 


不 同 分 支 里 反复 切换 ， 并 在 时 机 成 熟 时 把 它们 合并 到 一 起 。 而 所 有 这 些 工作 ,仅仅 需 要 branch 和 checkout 这 
两 条 命令 就 可 以 完成 。 











































































































E 3.9: 分 又 了 的 分 支 历 史 








由 于 Git 中 的 分 支 实 际 上 仪 是 一 个 包含 所 指 对 象 校 验 和 (40 个 字符 长 度 SHA-1 FE) 的 文件 ， 所 以 创建 
和 销毁 一 个 分 文 就 变 得 非常 廉价 。 说 白 了 ， 新 建 一 个 分 支 就 是 向 一 个 文件 写 入 41 SE (外 加 一 个 换行 符 ) 
那么 简单 ， 当 然 也 就 很 快 了 。 

这 和 大 多 数 版 本 控制 系统 形成 了 鲜明 对 比 ， 它 们 管理 分 支 大 多 采取 备份 所 有 项 目 文件 到 特定 目录 的 方式 ， 所 
以 根据 项 目 文件 数量 和 大 小 不 同 ， 可 能 花费 的 时 间 也 会 有 相当 大 的 差别 ， 快 则 几 秒 ， 慢 则 数 分 钟 。 而 Git 的 
实现 与 项 目 复杂 度 无 关 ， 它 永远 可 以 在 儿 营 秒 的 时 间 内 完成 分 支 的 创建 和 切换 。 同 时 ， 因 为 每 次 提交 时 都 记录 
了 祖先 信息 (译注 : BU parent 对 象 ) ， 所 以 以 后 要 合并 分 文 时 ， 寻 找 恰当 的 合并 基础 (译注 ， 即 共同 祖先 ) 
的 工作 其 实 已 经 完成 了 一 大 半 ， 实 现 起 来 非常 容易 。Git 鼓励 开发 者 频繁 使 用 分 支 ， 正 是 因为 有 着 这 些 特性 作 































































































































































































































































































接 下 来 看 看 ， 我 们 为 什么 应 该 频繁 使 用 分 支 。 














3.2 基本 的 分 支 与 合并 
现在 让 我 们 来 看 一 个 简单 的 分 支 与 合并 的 例子 ， 实 际 工作 中 大 体 也 会 用 到 这 样 的 工作 流程 



























































1. 开发 某 个 网 站 。 
2. 为 实现 某 个 新 的 需求 ， 创 建 一 个 分 支 。 
3. 在 这 个 分 文 上 开展 工作 。 





















































假设 此 时 ， 你 突然 接 到 一 个 电话 说 有 个 很 严重 的 问题 需要 紧急 修补 ， 那 么 可 以 按照 下 面 的 方式 处 理 : 
1. 返回 到 原先 已 经 发 布 到 生产 服务 器 上 的 分 支 。 

















2. 为 这 次 紧急 修补 建立 一 个 新 分 文 。 











再 推送 到 生产 服务 器 上 。 











3. 测试 通过 后 ， 将 此 修补 分 支 合并 ， 
































4. 切换 到 之 前 实现 新 需求 的 分 文 ， 继 续 工作 。 
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3.2.1 基本 分 支 
首先 ， 我 们 假设 你 正在 项 目 中 愉快 地 












































图 3.10) 












































图 3.10: 一 部 分 简短 的 提交 历史 











现在 ， 你 决定 要 修补 问题 追踪 系统 上 的 #53 问题 。 顺 带 说 明 下 ，Git 并 不 同 任何 特定 的 问题 追踪 系统 打 交 
道 。 这 里 为 了 说 明 要 解决 的 问题 ， 才 把 新 建 的 分 支取 名 为 iss53。 要 新 建 并 切换 到 该 分 支 ， 运 行 git checkout 
加 上 -o BR: 
























































$ git checkout -b iss53 


Switched to a new branch "iss53" 


相当 于 下 面 这 两 条 命令 : 








$ git branch iss53 
$ git checkout iss53 








RI 
CD 
zi 
Ent 
S 
E 
A 
Tm 
cT 
Av 
LH 
7H 














E 3.11: 创建 了 一 个 新 的 分 支 指针 

















妆 下 来 ， 你 在 网 站 项 目 上 继续 工作 并 作 了 一 次 提交 。 这 会 使 isss3 分 支 的 指针 随 着 提交 向 前 推进 ， 因 为 它 处 
于 检 出 状态 (或 者 说 ， 你 的 HEAD 指针 目前 正 指向 它 ， 见 图 3-12) : 



























































$ vim index.html 


$ git commit -a -m 'added a new footer [issue 53]' 














现在 你 就 接 到 了 那个 网 站 问题 的 紧急 电话 ， 需 要 马上 修补 。 有 了 Git ， 我 们 就 不 需要 同时 发 布 这 个 补丁 和 
iss53 里 作出 的 修改 ， 也 不 需要 在 创建 和 发 布 该 补丁 到 服务 器 之 前 花费 很 多 努力 来 复原 这 些 修改 。 唯 一 需要 的 
仅仅 是 切换 回 master 分 支 。 

不 过 在 此 之 前 ， 留 心 你 的 暂 存 区 或 者 工作 目录 里 ， 那 些 还 没有 提交 的 修改 ， 它 会 和 你 即将 检 出 的 分 支 产生 
冲突 从 而 阻止 Git 为 你 转换 分 文 。 转 换 分 支 的 时 候 最 好 保持 一 个 清洗 的 工作 区 域 。 稍 后 会 介绍 几 个 绕 过 这 种 



































naa 
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图 3.12: iss53 分 支 随 工作 进展 向 前 推进 

















a 

















本 的 分 支 与 合 





问题 的 办 法 (分 别 叫做 stashing 和 amending) 。 目 前 已 经 提交 了 所 有 的 修改 ， 所 以 接 下 来 可 以 正常 转换 到 








master 分 支 ， 


$ git checkout master 


Switched to branch "master" 














此 时 工作 目录 中 的 内 容 和 你 在 解决 问题 #3 之 前 一 模 一 样 ， 你 可 以 集中 精力 进行 紧急 修补 。 这 一 点 值得 
it 的 快照 。 它 会 自动 添加 、 删 除 和 



























































id: Git 会 把 工作 目录 的 内 容 恢 复 为 检 出 某 分 支 时 它 所 指向 的 那个 com 
改 文件 以 确保 目录 的 内 容 和 你 上 次 提交 时 完全 一 样 。 















































接 下 来 ， 你 得 进行 紧急 修补 。 我 们 创建 一 个 紧急 修补 分 文 (hotfix) 来 了 


3.13) : 


$ git checkout -b 'hotfix' 

Switched to a new branch "hotfix" 

$ vim index.html 

$ git commit -a -m 'fixed the broken email address' 
[hotfix]: created 3a0874c: "fixed the broken email address" 


1 files changed, 0 insertions(+), 1 deletions(-) 


























FII, 


图 3.13: hotfix 分 支 是 从 master 分 支 所 在 点 分 化 出 来 的 



































有 必要 作 些 测试 ， 确 保修 补 是 成 功 的 ， 然 后 把 它 合并 到 master 分 文 
令 来 进行 合并 : 


























$ git checkout master 


$ git merge hotfix 








发 布 到 4 








EP" BAS at ° 
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ur 
Tul 
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PR] 


到 搞定 〈 见 














a 
j git merge Ap 
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Updating f42c576..3a0874c 
Fast forward 
README | i 


1 files changed, 0 insertions(+), 1 deletions(-) 

















请 注意 ， 合 并 时 出 现 了 “Fast forward" ( 快 进 ) 提示 。 由 于 当前 master 分 支 所 在 的 commit 是 要 并 入 
hotfix 分 支 的 直接 上 游 ，Git 只 需 把 指针 直接 右 移 。 换 名 话说， 如 果 顺 着 一 个 分 支 走 下 去 可 以 到 达 另 一 个 
支 ， 那么 Git 在 合并 两 者 时 ， 只 会 简单 地 把 指针 前 移 ， 因 为 没有 什么 分 此 需要 解决 ， 所 以 这 个 过 程 叫做 快 
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Fast forward) œ 













































































































































































N 
qa 





DH 










































































现在 的 目录 变 为 当前 master 分 支 指向 的 commit 所 对 应 的 快照 ， 可 以 发 布 了 〈 见 图 3.14) 。 














图 3.14: 合并 之 后 ，master 分 支 和 hotfix 分 支 指向 同一 位 置 。 








o 


— 


在 那个 超级 重要 的 修补 发 布 以 后 ， 你 想 要 回 到 被 打扰 之 前 的 工作 。 因 为 现在 hotfix 分 支 和 master 指向 相同 
的 提交 ， 现 在 没什么 用 了 ， 可 以 先 删 掉 它 。 使 用 sit branch 的 -a 选项 表示 删除 : 









































$ git branch -d hotfix 
Deleted branch hotfix (3a0874c). 























现在 可 以 回 到 未 完成 的 问题 #53 分 文 继续 工作 了 (图 3-15) : 





$ git checkout iss53 

Switched to branch "iss53" 

$ vim index.html 

$ git commit -a -m 'finished the new footer [issue 53]' 
[iss53]: created ad82d7a: "finished the new footer [issue 53]" 


1 files changed, 1 insertions(*), 0 deletions(-) 
























































不 用 担心 hotfix 分 支 的 内 容 还 没 包含 在 iss53 2 如 果 确 5 3 :需要 纳入 此 次 RAE 可 以 j git merge master 把 
master 分 支 合 到 iss53, 或 者 等 完 wa, 再 将 iss53 分 支 的 更 新 并 入 master ° 






















































































3.2.2 基本 合并 


在 问题 #53 相关 的 工作 完成 之 后 ， 可 以 合并 回 master 分 文 ， 实 际 操作 同 前 面 合并 hotfix 分 支 差 不 多 ， 只 
需 检 出 想 要 更 新 的 分 a (master ) ; 运行 git merge 命令 指定 来 源 : 
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$ git checkout master 
$ git merge iss53 
Merge made by recursive. 


README | ils 











图 3.15: iss53 分 支 可 以 不 受 影响 继续 推进 。 


1 files changed, 1 insertions(+), 0 deletions(-) 


^ In 




















3.2 节 基 








本 的 分 支 与 合 



























































































































































并 不 同 于 之 前 hotfix 的 并 入 方式 。 这 一 次 ， 你 的 开发 历史 是 从 更 早 的 地 方 






































































































































































































Ly 


请 注意 ， 这 次 合并 的 实现 ， H 
分 又 的 。 由 于 当前 master 分 支 所 指向 的 commit 〈C4) 并 非 想 要 并 入 分 文 (iss53) 的 直接 祖先 ，Git 不 得 不 
进行 一 些 处 理 。 就 此 例 而 言 ，Git 会 用 两 个 分 支 的 末端 (C4 和 C5) 和 它们 的 共同 祖先 (C2) 进行 一 次 简单 的 
三 方 合并 计算 。 图 3.16 RET Git 在 用 于 合并 的 三 个 更 新 快照 : 

Merge Into 
Common 
Merge In 
A 3.16: Git 为 分 支 合并 自动 识别 出 最 佳 的 同 源 合并 点 。 

Git 没有 简单 地 把 分 支 指针 右 黎 ， 而 是 对 三 方 合并 的 结果 作 一 新 的 快照 ， 并 自动 创建 一 个 指向 它 的 
commit (C6) (WLR 3.17) 。 我 们 把 这 个 特殊 的 commit 称 作 合并 提交 (merge commit) ， 因 为 它 的 祖先 不 
Wo 

值得 一 提 的 是 Git 可 以 自己 裁决 哪个 共同 祖先 才 是 最 佳 合 并 基础 ， 这 和 CVS 或 Subversion (1.5 以 后 的 





























版 本 ) 不 同 ， 它 们 需要 














既然 你 的 工作 成 果 已 经 合并 了 ， 





















































发 者 手工 指定 合并 基础 。 所 以 此 特性 让 Git 的 合并 操作 比 
iss53 也 就 没 用 了 。 你 可 以 就 此 删除 它 ， 












































闭 。 





他 系统 都 要 简 
在 问题 追踪 系统 里 把 该 问题 关 











单 不 少 
































o 
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图 3.17: Git 自动 创建 了 一 个 包含 了 合并 结果 的 commit 对 象 。 
$ git branch -d iss53 


3.2.3 冲突 的 合并 

有 时 候 合并 操作 并 不 会 如 此 顺利 。 如 果 你 修改 了 两 个 待 合 并 分 支 里 同一 个 文件 的 同一 部 分 ，Git MEAT 
地 把 两 者 合 到 一 起 《译注 : 逻辑 上 说 ， 这 种 问题 只 能 由 人 来 解决 ) 。 如 果 你 在 解决 问题 853 的 过 程 中 修改 了 
hotfix 中 修改 的 部 分 ， 将 得 到 类 似 下 面 的 结 : 












































-| 






























































































































































N: 





$ git merge iss53 
Auto-merging index.html 
CONFLICT (content): Merge conflict in index.html 


Automatic merge failed; fix conflicts and then commit the result. 























Git 作 了 合并 ， 但 没有 提交 ， 它 会 停 下 来 等 你 解决 冲突 。 要 看 看 哪些 文件 在 合并 时 发 生 冲 突 ， 可 以 用 sit 


status 查阅 : 



































[master*]$ git status 
index.html: needs merge 
# On branch master 


# Changed but not updated: 


# (use "git add <file>..." to update what will be committed) 

# (use "git checkout -- <file>..." to discard changes in working directory) 
# 

# unmerged: index.html 

# 





























任何 包含 未 解决 冲突 的 文件 都 会 以 未 合并 (unmerged) 状态 列 出 。Git 会 在 有 冲突 的 文件 里 加 入 标准 的 冲突 
解决 标记 ， 可 以 通过 它们 来 手工 定位 并 解决 这 些 冲突 。 可 以 看 到 此 文件 包含 类 似 下 面 这 样 的 部 分 : 































































































<<<<<<< HEAD: index.html 
«div id="footer">contact : email.support@github.com</div> 


«div id="footer"> 
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please contact us at support@github.com 
</div> 


>>>>>>> iss53:index.html 

















可 以 看 到 ======= 陋 开 的 上 半 部 分 ， 是 HEAD (BM master 分 文 ， 在 运行 merge 命令 时 检 出 的 分 支 ) 中 的 内 
容 ， 下 半 部 分 是 在 iss53 分 支 中 的 内 容 。 解 决 冲突 的 办 法 无 非 是 二 者 选 其 一 或 者 由 你 亲自 整合 到 一 起 。 比 如 你 
可 以 通过 把 这 段 内 容 奉 换 为 下 面 这 样 来 解决 : 



























































































































































«div id= "footer "> 


please contact us at email.support@github.com 
































</div> 
这 个 解决 方案 各 采纳 了 两 个 分 文中 的 一 部 分 内 容 ， 而 且 我 还 删除 了 <<<<<<<，=======， 和 >>>>>>> 这 些 行 。 在 












































IT 






























































解决 了 所 有 文件 里 的 所 有 冲突 后 ， 运 行 git ada 将 把 它们 标记 为 已 解决 (resolved) 。 因 为 一 旦 暂 存 ， 就 表示 
冲突 已 经 解决 。 如 果 你 想 用 一 个 有 图 形 界面 的 工具 来 解决 这 些 问题 ， 不 妨 运行 sit nergetool， 它 会 调用 一 个 可 
视 化 的 合并 工具 并 引导 你 解决 所 有 冲突 : 















































































































































$ git mergetool 
merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff 
Merging the files: index.html 


Normal merge conflict for 'index.html': 
{local}: modified 
{remote}: modified 


Hit return to start merge resolution tool (opendiff): 






























































如 果 不 想 用 默认 的 合并 工具 (Git NRE X f opendiff， 因 为 我 在 Mac 上 运行 了 该 命令 ) ， 你 可 以 在 上 
Jj "merge tool candidates (候选 合并 工具 ) ”里 找到 可 用 的 合并 工具 列表 ， 输 入 你 想 用 的 工具 名 。 我 们 将 
在 第 七 章 讨论 怎样 改变 环境 中 的 默认 值 。 
























































































































































































































































退出 合并 工具 以 后 ，Git 会 询问 你 合并 是 否 成 功 。 如 果 回 答 是 ， 它 会 为 你 把 相关 文件 暂 存 起 来 ， 以 表明 状态 
为 已 解决 。 
再 运行 一 次 git status 来 确认 所 有 冲突 都 已 解决 : 


























$ git status 
# On branch master 


# Changes to be committed: 






























































# (use "git reset HEAD <file>..." to unstage) 
# 
# modified: ^ index.html 
# 
如 果 觉 得 满意 了 ， 确认 所 有 冲突 都 已 解决 ， 也 就 是 进入 了 缓存 区 ， 就 可 以 用 git commit 来 完成 这 次 合 



























































提交 。 提 交 的 记录 差不多 是 这 术 
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Merge branch 'iss53' 


Conflicts: 

index.html 
# 
# It looks like you may be committing a MERGE. 
# If this is not correct, please remove the file 
# .git/MERGE HEAD 


# and try again. 










































































































































































































































































































































































































































































# 

如 果 想 给 将 来 看 这 次 合并 的 人 一 些 方便 ， 可 以 修改 该 信息 ， 提 供 更 多 合并 细节 。 比 如 你 都 作 了 哪些 改动 ， 以 
及 这 么 做 的 原因 。 有 时 候 裁 决 冲突 的 理由 并 不 直接 或 明显 ， 有 必要 上 略 加 注解 。 
3.3 分 支管 理 

到 目前 为 上 上， 你 已 经 学 会 了 如 何 创建 、 合 并 和 删除 分 文 。 除 此 之 外 ,我们 还 需要 学 习 如 何 管理 分 支 ， 在 日 后 
的 常规 工作 中 会 经 常用 到 下 面 介绍 的 管理 命令 。 

git branch 命令 不 仅仅 能 创建 和 删除 分 支 ， 如 果 不 加 任何 参数 ， 它 会 给 出 当前 所 有 分 支 的 清单 : 
$ git branch 

iss53 
* master 

testing 

注意 看 master 分 支 前 的 * 字符 : 它 表 示 当 前 所 在 的 分 文 。 也 就 是 说 ， 如 果 现 在 提交 更 新 ，master 分 支 将 随 










































































着 开发 进度 前 移 。 若 要 查看 各 个 分 支 最 后 一 次 commit 信息 ， 运 行 git branc 
































git branch -v 


iss53 . 93b412c 
master 7a98805 
testing 782fd34 


fix javascript issue 
Merge branch 'iss53' 


add scott to the author list in the readmes 











AN 

















要 从 该 清单 ， 


























筛选 出 你 已 经 (或 尚未 ) 与 当前 分 支 合并 的 分 支 ， 可 以 用 


--merge 和 --no-merged 选项 (Git 
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Fi 

1.5.6 以 上 版 本 ) o 比如 git branch -merge 看 哪些 分 支 已 被 AX 前 分 支 : 
$ git branch --merged 

iss53 
* master 

之 前 我 们 已 经 合 iss53， 所 以 在 这 里 会 看 到 它 。 一 般 来 说 ， 列 表 中 没有 * 的 分 支 通 常 都 可 以 用 git branch 
-a 来 删 掉 。 原 因 很 简单 ， 既 然 已 经 把 它们 所 包含 的 工作 整合 到 了 其 他 分 支 ， 删 掉 也 不 会 损失 什么 。 

另外 可 以 用 git branch --no-merged 看 尚未 合并 的 工作 : 









































Scott Ch 


acon Pro Git 


$ git branch --no-merged 


testing 








我 们 会 看 到 其 余 还 未 合并 的 分 支 。 因 为 其 





$ git branch -d testing 


























' 还 包含 未 合并 的 工作 ， 


3.4 节 分 支 式 工作 流程 




















LN 























FH git branch -d 删除 该 





TTX 


error: The branch 'testing' is not an ancestor of your current HEAD. 






























































不 过 ， 如 果 你 坚信 你 要 删除 它 ， 可 以 
3.4 分 支 式 工作 流程 
如 今 有 了 分 支 与 合并 的 基础 ， 你 可 以 (或 应 该 ) 




















































































































































































































用 大 写 的 删除 选项 -p 强制 执行 ， 例 如 sit branch -D testing ° 



































TER BURT ANE? EAT, RiT 











会 介绍 些 使 用 分 文 进 行 











































































































































































































































































































































































































































































































发 的 工作 流程 。 而 正 是 由 于 分 支管 理 的 便捷 ， 才 衍生 出 了 这 类 典型 的 工作 模式 ， 有 机 会 可 以 实践 一 下 。 
3.4.1 长 期 分 支 
于 cit 使 用 简单 的 三 方 合并 ， 所 以 就 算 在 较 长 一 段 时 间 内 ， 反 复 多 次 把 某 个 分 支 合并 到 另 一 分 支 ， 也 不 

是 什么 难事 。 也 就 是 说 ， 你 可 以 同时 拥有 多 个 开放 的 分 文 ， 每 个 分 支 用 于 完成 特定 的 任务 ， 随 着 开发 的 推进 ， 
你 可 以 随时 把 某 个 特性 分 支 的 成 果 并 到 其 他 分 文中 。 

许多 使 用 Git 的 开发 者 都 喜欢 以 这 种 方式 来 开展 工作 ， 比 如 仅 在 master 分 文中 保留 完全 稳定 的 代码 ， 即 已 
经 发 布 或 即将 发 布 的 代码 。 与 此 同时 ， 他 们 还 有 一 个 名 为 develop 或 next 的 平行 分 支 ， 专 门 用 于 后 续 的 
发 ， 或 仅 用 于 稳定 性 测试 当然 并 不 是 说 一 定 要 绝对 稳定 ， 不 过 一 旦 进入 某 种 稳定 状态 ， 便 可 以 把 它 合 并 
到 master 里 。 这 样 ， 在 确保 这 些 已 完成 的 特性 分 支 (短期 分 支 ， 如 前 例 的 iss53) 能 够 通过 所 有 测试 ， 并 且 不 
会 引入 更 多 错误 之 后 ， 就 可 以 并 到 主干 分 支 中 ， 等 待 下 一 次 的 发 布 。 

本 质 上 我 们 刚才 谈论 的 ， 是 随 着 commit 不 停 前 移 的 指针 。 稳 定 分 支 的 指针 总 是 在 提交 历史 中 落后 一 大 截 ， 
而 前 沿 分 支 总 是 比较 靠 前 ( 见 图 3.18) 











它们 想象 成 - 



























































master develop 
(<)- (=)- (ce 小 («)- (s)- 


图 


eb A 


3.18: 稳定 分 支 总 是 比较 老 昌 。 



















































































































































































































































































把 [ 作 流 水 线 可 能 会 比较 容易 理解 ， 经 过 测试 的 commit 集合 被 洲 选 到 更 稳定 的 流水 线 
( 见 图 3.19) 

尔 可 以 用 这 招 维护 不 同 层次 的 稳定 性 。 某 些 大 项 目 还 会 有 个 proposed (建议 ) 或 pu (proposed updates, $ 
WER) 分 支 ， 它 包含 着 那些 可 能 还 没有 成 熟 到 进入 next 或 master 的 内 容 。 这 么 做 的 目的 是 拥有 不 同 层 次 的 
REE: 当 这 些 分 支 进入 到 更 稳定 的 水 平时 ， 再 把 它们 合并 到 更 高 层 分 支 中 去 。 再 次 说 明 下 ， 使 用 多 个 长 期 分 
支 的 做 法 并 非 必需 ， 不 过 一 般 来 说 ， 对 于 特大 型 项 目 或 特 复杂 的 项 目 ， 这 么 做 确实 更 容易 管理 。 


3.4.2 特性 分 支 





在 任何 规模 的 项 





























中 都 可 以 使 




















ne 

































































H 特性 (Topic) 分 支 。 一 个 特性 分 支 是 指 一 个 短期 的 ， 用 来 实现 单一 特性 或 
与 其 相关 工作 的 分 支 。 可 能 你 在 以 前 的 版 本 控制 系统 里 从 未 做 过 类 似 这 样 的 事 请 ， 因 为 通常 创建 与 合并 分 支 消 
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master (© | 


develop 


topic 


E 3.19: 想象 成 流水 线 可 能 会 容易 点 。 


























耗 太 大 。 然 而 在 Git 中 ， 一 天 之 内 建立 ， 使 用 ， 合 并 再 删除 多 个 分 支 是 常见 的 事 。 

我 们 在 上 节 的 例子 里 已 经 见 过 这 种 用 法 了 。 我 们 创建 了 iss53 和 notfix 这 两 个 特性 分 支 ， 在 提交 了 若干 更 
新 后 ， 把 它们 合并 到 主干 分 支 ， 然 后 删除 。 该 技术 允许 你 迅速 旦 完全 的 进行 语 境 切换 一 一 因为 你 的 工作 分 散 
在 不 同 的 流水 线 里 ， 每 个 分 支 里 的 改变 都 和 它 的 目标 特性 相关 ， 浏 览 代码 之 类 的 事情 因而 变 得 更 简单 了 。 你 可 
以 把 作出 的 改变 保持 在 特性 分 支 中 几 分 钟 ， 几 天 甚至 几 个 月 ， 等 它们 成 熟 以 后 再 合并 ， 而 不 用 在 乎 它们 建立 的 
顺序 或 者 进度 。 

现在 我 们 来 看 一 个 实际 的 例子 。 请 看 图 3.20， 起 先 我 们 在 master 工作 到 C1， 然后 开始 一 个 新 分 支 iss91 
尝试 修复 91 号 缺陷 ， 提 交 到 ce 的 时 候 ， 又 冒 出 一 个 新 的 解决 问题 的 想法 ， 于 是 从 之 前 C4 的 地 方 又 分 出 一 
个 分 支 issoive, FS] C8 的 时 候 ， 又 回 到 主干 中 提交 了 CO 和 C10， 再 回 到 iss91v2 继续 工作 ， 提 交 Cll, $ 
着 ， 又 冒 出 个 不 太 确 定 的 想法 ， 从 master 的 最 新 提交 C10 处 开 了 个 新 的 分 支 dumbidea 做 些 试验 。 
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图 3.20: 拥有 多 个 特性 分 支 的 提交 历史 。 








现在 ， 假 定 两 件 事情 : 我 们 最 终 决 定 使 用 第 二 个 解决 方案 ， 即 iss9lv2 中 的 办 法 ; 另外 ,我们 把 qunbidea 分 
文 拿 给 同事 们 看 了 以 后 ， 发 现 它 竟然 是 个 天 才 之 作 。 所 以 接 下 来 ， 我 们 抛弃 原来 的 iss91 分 支 ( 即 丢弃 C5 和 
C6) ， 直 接 在 主干 中 并 入 另外 两 个 分 文 。 最 终 的 提交 历史 将 变 成 图 3.21 这 样 : 

请 务必 牢记 这 些 分 支 全 部 都 是 本 地 分 文 ， 这 一 点 很 重要 。 当 你 在 使 用 分 文 及 合并 的 时 候 ， 一 切 都 是 在 你 自己 
的 Git 仓库 中 进行 的 一 一 完全 不 涉及 与 服务 器 的 交互 。 
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3.5% 远程 分 支 


图 3.21: 合并 了 dumbidea 和 iss91v2 以 后 的 历史 。 


3.5 远程 分 支 














远程 分 文 (remote branch) 是 对 远程 仓库 状态 的 索引 。 它 们 是 一 些 无 法 移动 的 本 地 分 支 ， 只 有 在 进行 Git 















































的 网 络 活动 时 才 会 更 新 。 远 程 分 文 束 像 是 书签 ,提醒 着 你 上 次 连接 远程 仓库 时 上 面 各 分 支 的 位 置 。 


































































































我 们 用 (远程 仓库 名 )/( 分 支 名 ) 这 样 的 形式 表示 远程 分 支 。 比 如 我 们 想 看 看 上 次 同 origin 仓库 通讯 























时 master 的 





样子 ， 就 应 该 查看 origin/master 分 文 。 如 果 你 和 同伴 一 起 修复 某 个 问题 ， 但 他 们 先 推送 了 一 个 isss3 分 支 到 远 
程 仓库 ， 虽 然 你 可 能 也 有 一 个 本 地 的 isss3 分 文 ， 但 指向 服务 器 上 最 新 更 新 的 却 应 该 是 origin/iss53 分 文 。 





































































































可 能 有 点 乱 ， 我 们 不 妨 举例 说 明 。 假 设 你 们 团队 有 个 地 址 为 git.ourcompany.com 的 Git 服务 器 。 如 果 你 从 这 


里 克隆 ，Git 会 自动 为 你 将 此 远程 仓库 命名 为 origin， 并 下 载 其 中 所 有 的 数据 ， 建 立 一 个 指向 它 的 master 分 
Git 建立 一 个 属于 你 自己 的 本 地 
master 分 支 ， 始 于 origin 上 master 分 文 相同 的 位 置 ， 你 可 以 就 此 开始 工作 〈 见 图 3.22) : 
























































支 的 指针 ， 在 本 地 命名 为 origin/master， 但 你 无 法 在 本 地 更 改 其 数据 。 接 着 ， 









































origin/master 分 支 的 最 后 一 次 提交 。 













































































要 是 你 在 本 地 master 分 支 做 了 会 儿 事 情 ， 与 此 同时 ， 其 他 人 向 git.ourcompany.com FEE SAA, Met SEE 



































的 master 分 支 ， 那么 你 的 提交 历史 会 开始 朝 不 同 的 方向 发 展 。 不 过 只 要 你 不 和 服务 器 通讯 ， 你 的 origin/master 








指针 不 会 移动 CLA 3.23) 。 

可 以 运行 git fetch origin 来 进行 同步 ? 该 命令 
从 上 面 获 取 你 尚未 拥有 的 数据 ， 更 新 你 本 地 的 数据 库 ， 然 后 把 origin/master 
3.24) 。 



















































































































































































项 目的 远程 分 支 之 一 。 我 们 把 它 命名 为 teanone， 表 示 那 一 整 串 Git 地 址 CW 
现在 你 可 以 用 git fetch teamone 来 获取 小 组 服务 器 上 你 还 没有 的 数据 了 。 

































































为 了 演示 拥有 多 个 远程 分 支 (不 同 的 远程 服务 器 ) 的 项 目 是 个 什么 样 ， 我 们 假设 你 还 有 另 一 个 仅 供 你 的 敏捷 
发 小 组 使 用 的 内 部 服务 器 git.teanl.ourcompany.com。 可 以 用 第 二 章 中 提 到 的 git remote add 命令 把 它 加 为 当前 








图 3.25) » 
































于 当前 该 服务 器 上 的 内 容 是 你 


先 找到 origin 是 哪个 服务 器 (本 例 为 git.ourcompany.com) ; 
的 指针 移 到 它 最 新 的 位 置 ( 见 图 





























origin 服务 器 上 的 子 集 ，Git 不 会 下 载 任何 数据 ， 而 只 是 简单 地 创建 一 个 名 为 teamone/master 的 分 支 来 指 癌 























teamone 服务 器 上 master 所 指向 的 更 新 31b8e ( 见 图 3.26) 9 
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Scott Chacon Pro Git 


git.ourcompany.com 


master 





{ git clone schacon@git.ourcompany.com:project.git 


My Computer 





Remote Branch 


^*----- Local Branch 


图 3.22: 一 次 Git 克隆 会 建立 你 自己 的 本 地 分 支 master 和 远程 分 支 origin/master， 它 们 都 指向 


5.1 


要 想 和 其 他 人 分 享 某 个 分 支 ， 你 需要 把 它 推送 到 一 个 你 扫 
到 你 引入 的 远程 分 支 中 ， 除 非 你 明确 执行 推送 操作 。 换 名 


支 ， 而 只 推送 那些 协同 工作 的 特性 分 支 。 


如 果 


git.ourcompany.com 


My Computer 





图 3.23: 在 本 地 工作 的 同时 有 人 向 远程 仓库 推送 内 容 会 让 提交 历史 发 生 分 歧 。 


推送 

































































MADI] serverfix 的 分 文 需要 和 他 人 一 起 天 





$ git push origin serverfix 


Counting objects: 20, done. 

Compressing objects: 100% (14/14), done. 
Writing objects: 100% (15/15), 1.74 KiB, done. 
Total 15 (delta 5), reused 0 (delta 0) 


To git@github.com:schacon/simplegit.git 


* [new branch] serverfix -> serverfix 
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FA, FLL 








有 写 权 限 的 远程 仓库 。 你 的 本 地 分 支 不 会 被 自动 同 









































话说 ， 对 于 无 意 分 享 的 ， 你 尽 可 以 保留 为 私人 分 


























运行 git push (远程 仓库 名 ) (分 支 名 ): 


3.5 * 远程 分 支 


Scott Chacon Pro Git 


git.ourcompany.com 


master 


{ git fetch origin 





My Computer 


= 





图 3.24: git fetch 命令 会 更 新 remote #4] ° 


git.ourcompany.com git.team1.ourcompany.com 





git remote add teamone git: //git.teami.ourcompany.com 


origin, ter 





图 3.25: 把 另 一 个 服务 器 加 为 远程 仓库 











这 其 实 有 点 像 条 捷径 。Git 自动 把 serverfix 分 支 名 扩展 为 refs/heads/serverfix:refs/heads/serverfix， 意 为 “ 取 
出 我 的 serverfix 本 地 分 文 ， 推 送 它 来 更 新 远程 仓库 的 serverfix 分 文 ”。 我 们 将 在 第 九 章 进一步 介绍 refs/ 
heads/ 部 分 的 细节 ， 不 过 一 般 使 用 的 时 用 都 可 以 省 略 它 2 也 可 以 运行 git push origin serverfix:serferfix 来 实 
现 相同 的 效果 ， 它 的 意思 是 “提取 我 的 serverfix 并 更 新 到 远程 仓库 的 serverfix”。 通 过 此 语法 ， 你 可 
以 把 本 地 分 支 推 送 到 某 个 命名 不 同 的 远程 分 支 ， 若 想 把 远程 分 支 叫 作 awesomebranch， 可 以 用 git push origin 
serverfix:awesomebranch 来 推送 数据 。 

接 下 来 ， 当 你 的 协作 者 再 次 从 服务 器 上 获取 数据 时 ， 他 们 将 得 到 一 个 新 的 远程 分 文 origin/serverfix: 




























































































4 







































































$ git fetch origin 


remote: Counting objects: 20, done. 
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git.ourcompany.com git.team1.ourcompany.com 





git fetch teamone 


My Computer 





图 3.26: 你 在 本 地 有 了 一 个 指向 teamone 服务 器 上 master 分 支 的 索引 。 


remote: Compressing objects: 100% (14/14), done. 
remote: Total 15 (delta 5), reused 0 (delta 0) 
Unpacking objects: 100% (15/15), done. 

From gitegithub.com:schacon/simplegit 


* [new branch] serverfix -> origin/serverfix 











值得 注意 的 是 ， 在 fetch 操作 抓 来 新 的 远程 分 支 之 后 ， 你 仍然 无 法 在 本 地 编辑 该 远程 仓库 。 换 句 话 说， 在 
本 例 中 ， 你 不 会 有 一 个 新 的 serverfix 分 文 ， 有 的 只 是 一 个 你 无 法 移动 的 origin/serverfix 指针 。 

如 果 要 把 该 内 容 合并 到 当前 分 支 ， 可 以 运行 sit merge origin/serverfix。 如 果 想 要 一 份 自己 的 serverfix 来 开 
发 ， 可 以 在 远程 分 文 的 基础 上 分 化 出 一 个 新 的 分 支 来 : 


























































































































$ git checkout -b serverfix origin/serverfix 
Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. 


Switched to a new branch "serverfix" 



































这 会 切换 到 新 建 的 serverfix 本 地 分 支 ， 内容 同 远程 分 支 origin/serverfix 一 致 ， 你 可 以 在 里 H 继续 开发 
T o 















































3.5.2 跟踪 分 支 



































从 远程 分 文 检 出 的 本 地 分 文 ， 称 为 跟踪 分 文 (tracking branch)。 跟 踪 分 文 是 一 种 和 远程 分 文 有 直接 联系 的 

本 地 分 文 。 在 跟踪 分 文 里 输入 git push, Git 会 自行 推断 应 该 向 哪个 服务 器 的 哪个 分 支 推 送 数 据 。 反 过 来 ， 在 
这 些 分 文 里 运行 zit pull 会 获取 所 有 远程 索引 ， 并 把 它们 的 数据 都 合并 到 本 地 分 文中 来 。 
在 克隆 仓库 时 ，Git 通常 会 自动 创建 一 个 master 分 支 来 跟踪 origin/master。 这 正 是 git push 和 git pull 一 开 
台 就 能 正常 工作 的 原因 。 当 然 ， 你 可 以 随心 所 欲 地 设 定 为 其 它 跟踪 分 文 ， 比 如 origin 上 除了 master 之 外 的 其 
它 分 支 。 刚 才 我 们 已 经 看 到 了 这 样 的 一 个 例子 : git checkout -b [分 支 名 ] [远程 名 ]/[ 分 支 名 ]。 如 果 你 有 1.6.2 E 
上 版 本 的 Git， 还 可 以 用 --track 选项 简化 : 
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$ git checkout --track origin/serverfix 
Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. 


Switched to a new branch "serverfix" 









































要 为 本 地 分 支 设 定 不 同 于 远程 分 支 的 名 字 ， 只 需 在 前 个 版 本 的 命令 里 换个 名 字 : 


























$ git checkout -b sf origin/serverfix 
Branch sf set up to track remote branch refs/remotes/origin/serverfix. 


Switched to a new branch "sf" 




















现在 你 的 本 地 分 支 sf 会 自动 向 origin/serverfix 推送 和 抓 取 数据 了 。 








































































































如 果 不 再 需要 某 个 远程 分 支 了 ， 比 如 搞定 了 菜 个 特性 并 把 它 合 并 进 了 远程 的 master 分 支 (或 任何 其 他 存放 
稳定 代码 的 地 方 ) ， 可 以 用 这 个 非常 无 厘 头 的 语法 来 删除 它 : git push [远程 名 ] :[ 分 支 名 ]。 如 果 想 在 服务 器 上 删 
除 serverfix 分 支 ， 运 行 下 面 的 命令 : 


































































































$ git push origin :serverfix 
To git@github.com:schacon/simplegit. git 


- [deleted] serverfix 



































B! 服务 器 上 的 分 支 没 了 。 你 最 好 特别 留心 这 一 页 ， 因 为 你 一 定 会 用 到 那个 命令 ， 而 且 你 很 可 能 会 筷 掉 它 的 
语法 。 Kan a 记 住 我 们 不 久 前 见 过 的 git push [远程 名 ] [本 地 分 支 ]:[ 远 程 分 支 ] 语法 ， 如 
省略 【本 地 分 那 就 等 于 是 在 说 “在 这 里 提取 空白 然后 把 它 变 成 [远程 分 支 ] © 



































































































































3.6 AA 














把 一 个 分 支 整 合 到 另 一 个 分 支 的 办 法 有 两 种 : merge (合并 ) 和 rebase (474) 。 在 本 章 我 们 会 学 习 什 么 是 衍 
合 ， 如 何 使 用 衍 合 ， 为 什么 衍 合 操作 如 此 富有 和 魅力， 以 及 我 们 应 该 在 什么 情况 下 使 用 衍 合 。 








































































































































































































请 回顾 之 前 有 关 合 并 的 一 节 OLA 3.27) ， 你 会 看 到 开发 进程 分 义 到 两 个 不 同 分 支 ， 又 各 自 提 交 了 更 新 。 
之 前 介绍 过 ， 最 容易 的 整合 分 支 的 方法 是 nerge 命令 ， 它 会 把 两 个 分 支 最 新 的 快照 (C3 和 C4) 以 及 二 者 最 
新 的 共同 祖先 (C2) 进行 三 方 合并 。 如 图 3.28 所 示 : 











































































































其 实 ， 还 有 另外 一 个 选择 : 你 可 以 把 在 C3 里 产生 的 变化 补丁 重新 在 C4 的 基础 上 打 一 壳 。 在 Git 里 ， 这 种 
操作 叫做 衍 合 (rebase) 。 有 了 rebase 命令 ,就 可 以 把 在 一 个 分 支 里 提交 的 改变 在 男 一 个 分 支 里 重 放 一 裔 。 


在 这 个 例子 里 ， 可 以 运行 下 面 的 命令 : 
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图 3.27: 











图 3.28: 通过 合并 一 个 分 支 来 整合 分 又 了 的 历史 。 


$ git checkout experiment 
$ git rebase master 
First, rewinding head to replay your work on top of it... 


Applying: added staged command 





























它 的 原理 是 回 到 两 个 分 文 〈 你 所 在 的 分 文 和 你 想 要 衍 合 进去 的 分 文 ) 的 共同 祖先 ， 提 到 你 所 在 分 支 每 次 提交 
时 产生 的 差异 (diff) ， 把 这 些 差 异 分 别 保存 到 临时 文件 里 ， 然 后 从 当前 分 支 转换 到 你 需要 衍 合 入 的 分 文 ， 依 
序 施用 每 一 个 差异 补丁 文件 。 图 3.29 演示 了 这 一 过 程 : 
















































































图 3.29: 把 C3 里 产生 的 改变 衍 合 到 C4 Te 













































































































































































































































































现在 ， 你 可 以 回 到 master 分 文 然后 进行 一 次 快 进 合并 OLA 3.30) : 

现在 ， 合 并 后 的 C3 ( 即 现在 的 C3' ) 所 指 的 快照 ， 同 三 方 合 并 例子 中 的 Co 所 指 的 快照 内 容 一 模 一 样 了 。 
最 后 整合 得 到 的 结果 没有 任何 区 别 ， 但 衍 合 能 产生 一 个 更 为 整洁 的 提交 历史 。 如 果 视 察 一 个 衍 合 过 的 分 支 的 历 
史记 录 ， 看 起 来 更 清楚 : 仿佛 所 有 修改 都 是 先后 进行 的 ， 尽 管 实际 上 它们 原来 是 同时 发 生 的 。 

你 可 以 经 党 使 用 衍 合 ， 确 保 在 远程 分 支 里 的 提交 历史 更 清晰 。 比 方 说 ， 某 些 项 目 自己 不 是 维护 者 ， 但 想 帮 
点 忙 ， 就 应 该 尽 可 能 使 用 衍 合 : 先 在 一 个 分 文 里 进行 开发 ， 当 准备 向 主 项 目 提 交 补 丁 的 时 候 ， 再 把 它 衍 合 到 
































































































































origin/master 里 面 。 这 样 ， 维 护 者 就 不 需要 做 任何 整合 工作 ， 只 需 根据 你 提供 的 仓库 地 址 作 一 次 快 进 ， 或 者 采 
纳 你 提交 的 补丁 。 
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master 


图 3.30: master 分 支 的 快 进 。 


















































请 注意 ， 合 并 结果 中 最 后 一 次 提交 所 指向 的 快照 ， 无 论 是 通过 一 次 衍 合 还 是 一 次 三 方 合并 ， 都 是 同样 的 快照 


Tum, A 
内 容 ， 只 是 提交 的 历史 不 同 轩 了 。 衍 合 按照 每 行 改变 发 生 的 次 序 重演 发 生 的 改变 ， 而 合并 是 把 最 终结 采 合 在 








































































































3.6.2 更 多 有 趣 的 衍 合 


你 还 可 以 在 衍 合 分 支 以 外 的 地 方 衍 合 。 以 图 3.31 的 历史 为 例 。 你 创建 了 一 个 特性 分 文 server 来 给 服务 器 
端 代 码 添 加 一 些 功能 ， 然 后 提交 C3 和 C4。 然 后 从 C3 的 地 方 再 增加 一 个 client 分 支 来 对 客户 端 代码 进行 一 


些 修 改 ,， 提交 C8 和 C9。 最后， 又 回 到 server 分 支 提交 了 C10。 





















































H 











图 3.31: 从 一 个 特性 分 支 里 再 分 出 一 个 特性 分 支 的 历史 。 
































假设 在 接 下 来 的 一 次 软件 发 布 中 ， 你 决定 把 客户 端的 修改 先 合 并 到 主线 中 ， 而 暂缓 并 入 服务 端 软件 的 修改 
《因为 还 需要 进一步 测试 ) 。 你 可 以 仅 提取 对 客户 端的 改变 (C8 和 C9) ,然后 通过 使 用 sit rebase 的 --onto 
选项 来 把 它们 在 master 分 支 上 重演 : 

















$ git rebase --onto master server client 























ni 

















这 基本 上 等 于 在 说 “ 检 出 client 分 支 ， 找 出 client 分 支 和 server 分 文 的 共同 祖先 之 后 的 变化 ， 然 后 
们 在 master 上 重演 一 裔 ”。 是 不 是 有 点 复杂 ? 不 过 它 的 结果 ， 如 图 3.32 所 示 ， 非 常 酷 ; 
现在 可 以 快 进 master 分 支 了 LAI 3.33) : 
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C8 C9 


图 3.32: 衍 合 一 个 特性 分 支 上 的 另 一 个 特性 分 支 。 


$ git checkout master 


$ git merge client 


o0 0-00 


B-a- 


图 3.33: at master 分 支 ， 使 之 包含 client 分 支 的 变化 。 
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现在 你 决定 把 server 分 支 的 变化 也 包含 进来 。 可 以 直接 把 server MTA master 而 不 用 手工 转 到 server 


























分 文 再 衍 合 。git rebase [ 主 分 支 ] [特性 分 支 ] 命令 会 先 检 出 特性 分 支 server， 然 后 在 主 分 支 master 上 重演 : 























$ git rebase master server 




















于 是 server 的 进度 应 用 到 master 的 基础 上 ， 如 图 3.34: 


-OO 











图 3.34: 在 master PR EMF server 分 支 。 














然后 快 进 Æ 分 支 master: 
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$ git checkout master 


$ git merge server 





现在 client 和 server 分 支 的 变化 都 被 整合 了 ， 不 妨 删 掉 它 们 ， 把 你 的 提交 历史 变 成 图 3.35 的 样子 : 


$ git branch -d client 


$ git branch -d server 


3.6.3 衍 合 的 风险 

















o 0-0-0-0-0- 0-0 
ea 




















蚌 ， 奇 妙 的 衍 合 也 不 是 完美 无 缺 的 ， 一 句 话 可 以 总 结 这 点 : 
永远 不 要 衍 合 那些 已 经 推送 到 公共 仓库 的 更 新 。 






















































































如 果 你 遵循 这 条 人 金 科 玉 得 




















， 就 不 会 出 差错 。 和 否则 ， 人 民 和 群众 会 仇恨 你 ， 你 的 朋友 和 家 人 也 会 别 笑 你 ， 唾 弃 

















在 衍 合 的 时 候 ， 实 际 上 抛弃 了 一 些 现存 的 commit 而 创造 了 一 些 类 似 但 不 同 的 新 commit。 如 果 你 把 commit 
推送 到 某 处 然后 其 他 人 下 载 并 在 其 基础 上 工作 ， 然 后 你 用 mit rebase 重 写 了 这 些 commit 再 推送 一 次 ， 你 的 合 
作者 就 不 得 不 重新 合并 他 们 的 工作 ， 这 样 当 你 再 次 从 他 们 那里 获取 内 容 的 时 候 事情 就 会 变 得 一 团 粳 。 
下 面 我 们 用 一 个 实际 例子 来 说 明 为 什么 公开 的 衍 合 会 带 来 问题 。 假 设 你 从 一 个 中 央 服 务 器 克隆 然后 在 它 的 基 


































































































































































































础 上 搞 了 一 些 开发 ， 提 交 历 史 类 似 图 3.36: 











git.team1.ourcompany.com 





My Computer 


ci 


"GM =a 


图 3.36: 克隆 一 个 仓库 ， 在 其 基础 上 工作 一 番 。 



































现在 ， 其 他 人 进行 了 一 些 包 含 一 次 合并 的 工作 (得 到 结果 C6) ,然后 把 它 推送 到 了 中 央 服 务 器 。 你 获取 了 



























































I 








这 些 数据 并 把 它们 合并 到 你 本 地 的 开发 进程 里 ， 让 你 的 历史 变 成 类 似 图 3.37 这 样 : 












































63 


第 3 章 Git OX Scott Chacon Pro Git 


git.team1.ourcompany.com 





My Computer 





图 3.37: 获取 更 多 提交 ， 并 入 你 的 开发 进程 。 



































接 下 来 ， 那 个 推送 C6 上 来 的 人 决定 用 衍 合 取 代 那 次 合并 ， 他 们 用 eit push --force 覆盖 了 服务 器 上 的 历史 ， 
得 到 C4”。 然后 你 再 从 服务 器 上 获取 更 新 : 


git.team1.ourcompany.com 












































€) teamone/master 


C4 


^L - ] 





图 3.38: 有 人 推送 了 衍 合 过 的 C4”， 丢 弃 了 你 作为 开发 基础 的 C6 。 








这 时 候 ， 你 需要 再 次 合并 这 些 内 容 ， 尽 管 之 前 已 经 做 过 一 次 了 。 衍 合 会 改变 这 些 commit 的 SHA-1 校 验 
值 ， 这 样 Git 会 把 它们 当 作 新 的 commit， 然 而 这 时 候 在 你 的 提交 历史 早 就 有 了 C4 的 内 容 ( 见 图 3.39) : 
你 迟早 都 是 要 并 入 其 他 协作 者 提交 的 内 容 的 ， 这 样 才能 保持 同步 。 当 你 做 完 这 些 ， 你 的 提交 历史 里 会 同时 
A cd 和 C4”， 两 者 有 着 不 同 的 SHA-1 校 验 值 ， 但 却 拥 有 一 样 的 作者 日 期 与 提交 说 明 ， 令 人 费解 ! 更 糟糕 的 
是 ， 当 你 把 这 样 的 历史 推送 到 服务 器 ， 会 再 次 把 这 些 衍 合 的 提交 引入 到 中 央 服 务 器 ， 进 一 步 迷 惑 其 他 人 。 

如 果 把 衍 合 当成 一 种 在 推送 之 前 清理 提交 历史 的 手段 ， 而 且 仅 仅 衍 合 那些 永远 不 会 公开 的 commit， 那 就 不 
会 有 任何 问题 。 如 有 果 衍 合 那 些 已 经 公开 的 commit， 而 与 此 同时 其 他 人 已 经 用 这 些 commit 进行 了 后 续 的 开发 
ITE, RAMAT ° 





























































































































































































































































































































ES 





























， 你 应 该 已 经 学 会 了 如 何 创建 分 支 并 切换 到 新 分 支 ， 在 不 同 分 支 间 转换 ， 合 并 本 地 分 支 ， 把 分 支 推 
送 到 共享 服务 器 上 ， 同 世界 分 享 ， 使 用 共享 分 文 与 他 人 协作 ;以 及 在 分 享 之 前 进行 衍 合 。 
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git.team1.ourcompany.com 


Da 


oO oO 





My Computer 





图 3.39: 你 把 相同 的 内 容 又 合并 了 一 遍 ， 生 成 一 个 新 的 提交 C8。 
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Scott Chacon Pro Git 


























到 目前 为 止 ， 你 应 该 已 经 学 会 了 使 用 Git 来 完成 日 常 的 工作 。 然 而 ， 如 采 想 与 他 人 合作 ， 还 需要 一 个 远程 
的 Git 仓库 。 尽 管 技术 上 可 以 从 个 人 的 仓库 里 推送 和 拉 取 改变 ， 但 是 我 们 不 鼓励 这 样 做 ， 因 为 一 不 留心 就 很 
容易 弄 混 其 他 人 的 进度 。 男 外 ， 你 也 一 定 希 望 合 作者 们 即使 在 自己 不 开机 的 时 候 也 能 从 仓库 获取 数据 一 一 拥有 
个 更 稳定 的 公共 仓库 十 分 有 用 。 因 此 ， 更 好 的 合作 方式 是 建立 一 个 大 家 都 可 以 访问 的 共享 仓库 ， 从 那里 推送 
和 拉 取 数据 。 我 们 将 把 这 个 仓库 称 为 "cit 服务 器 ”; 代理 一 个 Git 仓库 只 需要 花费 很 少 的 资源 ， 几 乎 从 不 
需要 整个 服务 器 来 支持 它 的 运行 。 

架设 一 个 Git 服务 器 不 难 。 第 一 步 是 选择 与 服务 器 通讯 的 协议 。 本 章 的 第 一 节 将 介绍 可 用 的 协议 以 及 他 们 
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各 自 的 优 缺 点 。 下 面 一 节 将 介绍 一 些 针 对 各 个 协议 典型 的 设置 以 及 如 何在 服务 器 上 运行 它们 。 最 后 ， 如 果 你 不 
介意 在 其 他 人 的 服务 器 上 保存 你 的 代码 ， 又 不 想 经 历 自己 架设 和 维护 服务 器 的 麻烦 ， 我 们 将 介绍 几 个 网 络 上 的 
MEN 


库 托管 服务 。 







































































































































































如 果 你 对 架设 自己 的 服务 器 没 兴 趣 ， 可 以 跳 到 本 章 最 后 一 节 去 看 看 如 何 创建 一 个 代码 托管 账户 然后 继续 下 一 
章 ， 我 们 会 在 那里 讨论 一 个 分 布 式 源码 控制 环境 的 林林总总 。 

常 只 是 一 个 纯 仓库 (bare repository) 个 没有 当前 工作 目录 的 仓库 。 因 为 该 仓库 只 是 一 
个 合作 媒介 ， 所 以 不 需要 从 一 个 处 于 已 从 硬盘 上 检 出 状态 的 快照 ; 仓库 里 仅仅 是 Git 的 数据 。 简 单 的 说 ， 纯 
仓库 是 你 项 目 里 .git 目录 的 内 容 ， 别 无 他 物 。 








































































































远程 仓库 通 


















































































































































4.1 协议 














Git 可 以 使 用 四 种 主要 的 协议 来 传输 数据 ; 本 地 传输 ，SSH 协议 ，Git 协议 和 HTTP 协议 。 下 面 分 别 介绍 一 
下 他 们 以 及 你 应 该 〈 或 不 应 该 ) 在 怎样 的 情形 下 使 用 他 们 。 
值得 注意 的 是 除了 HTTP 协议 之 外 ， 其 他 所 有 协议 都 要 求 在 服务 器 端 安装 并 运行 Git 。 
































































































































4.1.1 本 地 协议 


最 基础 的 就 是 本 地 协议 (Local protocol) 了 ， 远 程 仓 库 在 该 协议 中 就 是 硬盘 上 的 另 一 个 目录 。 这 常见 于 
团队 每 一 个 成 员 都 对 一 个 共享 的 文件 系统 (例如 NES. ) 拥 有 访问 权 ， 抑 或 比较 少见 的 多 人 共用 同一 台电 脑 的 时 
候 。 后 者 不 是 很 理想 ， 因 为 你 所 有 的 代码 仓库 实例 都 储存 在 同一 台电 脑 里 ， 增 加 了 灾难 性 数据 损失 的 可 能 性 。 

如 果 你 使 用 一 个 共享 的 文件 系统 ， 就 可 以 在 一 个 本 地 仓库 里 克隆 ， 推 送 和 获取 。 要 从 这 样 的 仓库 里 克隆 或 者 
将 其 作为 远程 仓库 添加 现 有 工程 里 ， 可 以 用 指向 该 仓库 的 路 径 作 为 URL。 比 如 ， 殉 隆 一 个 本 地 仓库 ， 可 以 用 如 
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$ git clone /opt/git/project.git 
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或 者 这 样 : 











$ git clone file:///opt/git/project.git 












































如 果 你 在 URL 的 开头 明确 的 使 用 file:// ， 那 么 Git 会 以 一 种 略微 不 同 的 方式 运行 。 如 果 你 只 给 出 路 径 ，Git 
会 尝试 使 用 硬 链 接 或 者 直接 复制 它 需 要 的 文件 。 如 有 果 使 用 了 file:// ，Git 会 调用 它 平 时 通过 网 络 来 传输 数据 
的 工序 ， 而 这 种 方式 的 效率 相对 很 低 。 使 用 file:// 前 缀 的 主要 原因 是 当 你 需要 一 个 不 包含 无 关 引 用 或 对 象 的 
净 仓 库 副 本 的 时 候 般 是 从 其 他 版 本 控制 系统 的 导入 之 后 或 者 类 似 的 情形 《参见 第 9 章 的 维护 任务 ) 
我 们 这 里 使 用 普通 路 径 ， 因 为 通常 这 样 总 是 更 快 。 

要 添加 一 个 本 地 仓库 到 现 有 Git 工程 ， 运 行 如 下 命令 : 
















































































































































































































































































































































































$ git remote add local proj /opt/git/project.git 








然后 就 可 以 像 在 网 络 上 一 样 向 这 个 远程 仓库 推送 和 获取 数据 了 。 
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基于 文件 仓库 的 优点 在 于 它 的 简单 ， 同 时 保留 了 现存 文件 的 权限 和 网 络 访问 权限 。 如 果 你 的 团队 已 经 有 一 个 
体 共 享 的 文件 系统 ， 建 立 仓库 就 十 分 容易 了 。 你 只 需 把 一 份 纯 仓 库 的 副本 放 在 大 家 能 访问 的 地 方 ， 然 后 像 对 
他 共享 目录 一 样 设置 读 写 权 限 就 可 以 了 。 我 们 将 在 下 一 入 “在 服务 器 上 部 署 Git” 中 讨论 如 何 为 此 导出 一 个 
仓库 的 副本 。 
这 也 是 个 从 别人 工作 目录 里 获取 他 工作 成 果 的 快捷 方法 。 假 如 你 和 你 的 同事 在 一 个 项 目 中 合作 ， 他 们 想 让 你 
检 出 一 些 东 西 的 时 候 ， 运 行 类 似 git pull /home/john/project 通常 会 比 他 们 推送 到 服务 器 ， 而 你 又 从 服务 器 获取 
简单 得 多 。 
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Li 
Gtr 
















































































































































































缺点 
你 想 从 家 












































这 种 方法 的 缺点 是 ， 与 基本 的 网 络 连接 访问 相 比 ， 能 从 不 同 的 位 置 访问 的 共享 权限 难以 架设 。 如 刁 
里 的 笔记 本 电脑 上 推送 ， 就 要 先 挂 载 远程 硬盘 ， 这 和 基于 网 络 连接 的 访问 相 比 更 加 困难 和 缓慢 。 

另 一 个 很 重要 的 问题 是 该 方法 不 一 定 就 是 最 快 的 ， 尤 其 是 对 于 共享 挂 载 的 文件 系统 。 本 地 仓库 只 有 在 你 对 数 
据 访问 速度 快 的 时 候 才 快 。 在 同一 个 服务 器 上 ， 如 果 二 者 同时 允许 Git 访问 本 地 硬 弄 ， 通 过 NFS 访问 仓库 通 
常会 比 SSH 慢 。 

































































































































































































































































4.1.2 SSH 协议 












































Git 使 用 的 传输 协议 中 最 常见 的 可 能 就 是 SSH 了 。 这 是 因为 大 多 数 环境 已 经 支持 通过 SSH 对 服务 器 的 访 
问 一 一 即使 还 没有 ， 也 很 容易 架设 。SSH 也 是 唯一 一 个 同时 便于 读 和 写 操 作 的 网 络 协议 。 另 外 两 个 网 络 协议 
(HTTP 和 Git) 通常 都 是 只 读 的 ， 所 以 虽然 二 者 对 大 多 数 人 都 可 用 ， 但 执行 写 操作 时 还 是 需要 SSH e SSH [n] 
时 也 是 一 个 验证 授权 的 网 络 协 议 ， 而 因为 其 普遍 性 ， 通 常 也 很 容易 架设 和 使 用 。 

通过 SSH 克隆 一 个 Git 仓库 ， 你 可 以 像 下 面 这 样 给 出 ssh:// 的 URL: 
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$ git clone ssh://user@server:project.git 
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不 指明 

















个 协议 一 一 这 时 Git 会 





$ git clone user@server:project.git 


也 可 以 不 指明 用 
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架设 相对 














类 似 Git 和 


缺点 
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SSH : 
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本 地 协议 ， 
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通过 SSH 进行 访问 
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4.1 节 协议 
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SSH 的 限制 在 了 
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用 的 协议 。 如 果 想 
他 协议 来 让 别人 获取 数据 。 
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4.1.3 Git 协议 
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使 仅 为 读 取 数 j 








压缩 数据 。 




















所 有 数据 传输 都 是 加 密 和 授权 的 。 


局 ， 人 们 也 必须 在 能 通过 SSH 访问 主 








这 使 得 SSH AAA 
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这 是 一 个 包含 在 Git 软件 包 ， 





© 如果 你 仅 
那么 除了 为 


又 在 公司 


网 络 里 



































die 





送 而 架设 




















(9418) 




















E, 
制 | ， 


要 么 谁 





























优点 
Git 协 


议 是 现存 最 | 





行 授 权 的 庞大 项 目 ， 














机 制 ， 但 




















ACC HS aay 
pc d do ee 
也 不 能 。 
i Da IUE 


的 传输 协议 。 如 细 


架设 一 个 Git 守护 ; 


的 特殊 守护 进程 ; 





它 会 监 监听 一 个 











J cit 协议 运营 








i 





一 但 除 此 之 外 i 








FIRB? 











意味 着 该 协议 通 


























个 知道 项 









































省 去 了 加 密 和 授权 的 开销 。 





缺点 




















你 在 提 
进程 























来 供 





NA 











f] 
没有 
常 不 能 用 来 进行 推送 。 你 
URL 的 人 将 都 有 推 


共 一 个 有 很 大 访问 上 
仓库 是 个 不 错 的 选择 


车 ， 


你 需要 创 














么 安全 措 








施 。 

















«TA fei 


Fix BRE; 





























送 权限 。 不 





建 git-export-daemon-ok 文件 一 一 它 


要 么 所 





HY 
























































SSH n] p 唯 


需要 





使 用 ， 
SSH 协议 之 外 ， 





提供 类 似 于 SSH 服务 


Cu 








有 人 都 能 克隆 Git 
然而 由 于 没有 授权 机 


分 


Ls 






































Ji, 


这 是 











分 罕见 的 情况 。 























Git 协议 ; 





HARE 

















El 




















同时 


提供 





SSH 接 








7E, 





能 也 是 最 难 架设 的 协议 。 它 要 求 有 单独 的 入 
绍 它 的 架设 一 一 需要 设 定 xinetd 或 类 


而 企业 级 防火 墙 




















端口 ， 





4.1.4 HTTP/S 协议 


a 


最 后 还 有 














库 文 件 放 在 HTTP 的 文件 根 





见 第 七 章 
以 允许 通 ; 





























， 让 几 个 开发 


面 是 缺少 授权 机 制 。 





j Git 协议 作为 








ay} 


访问 项 











时 的 公共 





项 目 





, a 





FESTE 


的 唯 









































一 个 不 需要 对 读 操 作 进 


j5 SSH 协议 相同 的 数据 传输 

















方法 











推送 ( 写 ) 权限 ， 











一 般 不 允许 对 这 个 









































护 进程 ， 需 要 定 第 












































以 的 得 





HTTP 协议 。HTTP 或 HTTPS 协议 

















EHE, muU 
准 端口 的 访问 。 























韭 标 

















录 下 ， 配 置 





o MIK, 









































的 优美 之 处 在 于 架设 的 简便 性 
个 特定 的 post-update 挂钩 (hook) 
每 个 能 访问 Git 仓库 所 在 服务 器 上 的 web 服务 的 人 者 
X HTTP 对 仓库 进行 读 取 : 


他 人 通过 git:// D 
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$ cd /var/www/htdocs/ 

$ git clone --bare /path/to/git project gitproject.git 
$ cd gitproject.git 

$ mv hooks/post-update.sample hooks/post-update 

$ chmod a*x hooks/post-update 














这 样 就 可 以 J o Git 附带 的 post-update 挂钩 会 默认 运行 合适 的 命 4 (git update-server-info) 来 确 保 通过 
HTTP 的 获取 和 克隆 正常 工作 。 这 条 命令 在 你 用 SSH 向 仓库 淮 送 内 容 时 运 和 T; 之 后 ， 其 他 人 就 可 以 用 下 面 的 命 
令 来 克隆 仓库 : 


























































































































$ git clone http://example.com/gitproject.git 






































在 本 例 中 ， 我 们 使 用 了 Apache 设 定 中 常用 的 /var/www/htdocs 路 径 ， 不 过 你 可 以 使 用 任何 静态 web 服务 
一 一 把 纯 仓库 放 在 它 的 目录 里 就 行 了 。 Git 的 数据 是 以 最 基本 的 静态 文件 的 形式 提供 的 (关于 如 何 提 供 文件 
的 详情 见 第 9 章 ) 。 
通过 HTTP 进 行 推送 操作 也 是 可 能 的 ， 不 过 这 种 做 法 不 太 常 见 并 且 牵 扯 到 复杂 的 WebDAV 设 定 。 由 于 很 
少 用 到 ， 本 书 将 略 过 对 该 内 容 的 讨论 。 如 果 对 HTTP 推送 协议 感 兴趣 ， 不 妨 在 这 个 地 址 看 一 下 操作 方 
YE: http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt 。 通 过 
HTTP 推送 的 好 处 之 一 是 你 可 以 使 用 任何 WebDAV 服务 器 ， 不 需要 为 Git 设 定 特殊 环境 ， 所 以 如 果 主 机 提供 商 
支持 通过 WebDAV 更 新 网 站 内 容 ， 你 也 可 以 使 用 这 项 功能 
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优点 


使 用 HTTP 协议 的 好 处 是 易于 架设 。 几 条 必要 的 命令 就 可 以 让 全 世界 读 取 到 仓库 的 内 容 。 人 花费 不 过 几 分 
钟 。HTTP 协议 不 会 占用 过 多 服务 器 资源 。 因 为 它 一 般 只 用 到 静态 的 HTTP 服务 提供 所 有 的 数据 ， 普 通 的 
Apache 服务 器 平均 每 秒 能 供应 数 千 个 文件 一 一 哪怕 是 让 一 个 小 型 的 服务 器 超载 都 很 难 。 

你 也 可 以 通过 HTTPS 提供 只 读 的 仓库 ， 这 意味 着 你 可 以 加 密 传输 内 容 ， 你 甚至 可 以 要 求 客户 端 使 用 特定 签 
名 的 SSL 证 书 。 一 般 情 况 下 ， 如 果 到 了 这 一 步 ， 使 用 SSH 公共 和 密 钥 可 能 是 更 简单 的 方案 ; 不 过 也 存在 一 些 特 
殊 情 况 ， 这 时 通过 HTTPS 使 用 带 签 名 的 SSL 证 书 或 者 其 他 基于 HTTP 的 只 读 连 接 授权 方式 是 更 好 的 解决 方 
案 。 

HTTP 还 有 个 额外 的 好 处 : HTTP 是 一 个 如 此 和 常见 的 协议 ， 以 至 于 企业 级 防火 墙 通常 都 允许 其 端口 的 通信 。 
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缺点 


HTTP 协议 的 消极 面 在 于 ， 相 对 来 说 客户 端 效 率 更 低 。 克 隆 或 者 下 载 仓 库 内 容 可 能 会 花费 更 多 时 间 ， 而 且 
HTTP 传输 的 体积 和 网 络 开销 比 其 他 任何 一 个 协议 都 大 。 因 为 它 没有 按 需 供应 的 能 力 一 一 传输 过 程 中 没有 服务 

端的 动态 计算 Ali HTTP 协议 经 常会 被 称 为 Bel (dumb) 协议 。 更 多 HTTP 协议 和 其 他 协议 效率 上 的 差异 
见 第 九 章 。 





























































































































































































































4.2 在 服务 器 部 署 Git 





























开始 架设 Git 服务 器 的 时 候 ， 需 要 把 一 个 现存 的 仓库 导出 为 新 的 纯 仓库 一 一 不 包含 当前 工作 目录 的 仓库 。 
方法 非常 直截了当 。 把 一 个 仓库 克隆 为 纯 人 仓库， 可 以 使 用 clone 命令 的 --bare 选项 。 纯 仓库 的 目录 名 以 
.git 结尾 ， 如 下 : 
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$ git clone --bare my project my project.git 
Initialized empty Git repository in /opt/projects/my project.git/ 








































































































该 命令 的 输出 有 点 迷惑 人 。 由 于 clone 基本 上 等 于 git init 加 git fetcn， 这 里 出 现 的 就 是 sit init 的 输出 ， 
它 建立 了 一 个 空 目录 。 实 际 的 对 象 转 换 不 会 有 任何 输出 ， 不 过 确实 发 生 了 。 现 在 在 my_project.git 中 已 经 有 了 

























































































一 份 Git 目录 数据 的 副本 。 
大 体 上 相当 于 


























$ cp -Rf my_project/.git my_project.git 




























































































在 配置 文件 中 有 几 个 小 改变 ， 不 过 从 效果 角度 讲 ， 克 隆 的 内 容 是 一 样 的 。 它 仅 包 含 了 Git 目录 ,没有 工作 
X, 专门 为 之 (译注: Git 目录 ) 建立 了 一 个 单独 的 目录 。 

























































































4.2.1 将 纯 目录 转移 到 服务 器 















































有 了 仓库 的 纯 副 本 以 后 ， 剩 下 的 就 是 把 它 放 在 服务 器 上 并 设 定 相关 的 协议 。 假 设 一 个 域名 为 git.example.com 
的 服务 器 已 经 架设 好 ， 并 可 以 通过 SSH 访问 ， 而 你 想 把 所 有 的 Git 仓库 储存 在 /opt/git 目录 下 。 只 要 把 纯 仓 
库 复制 上 去 : 





































































































$ scp -r my project.git user@git.example.com:/opt/git 





















































现在 ， 其 他 对 该 服务 器 具有 SSH 访问 权限 并 可 以 读 取 /ovt/git PYAR PA] LAIR io ook: 















































$ git clone user@git.example.com:/opt/git/my_project.git 



























































假如 一 个 SSH 用 户 对 /opt/git/my project.git H UB STEUR , 他 会 自动 具 有 推送 权限 o 这 时 如 果 运 行 git init 
命令 的 时 候 加 上 -shared 选项 ，Git 会 自动 对 该 仓库 加 入 可 写 的 组 。 


























$ ssh user@git.example.com 
$ cd /opt/git/my project.git 


$ git init --bare --shared 











































































































































































































可 见 选 择 一 个 Git 仓库 ， 创 建 一 个 纯 的 版 本 ， 最 后 把 它 放 在 你 和 同事 都 有 SSH 访问 权 的 服务 器 上 是 多 么 容 
j 。 现 在 已 经 可 以 开始 在 同一 项 目 上 密切 合作 了 。 

值得 注意 的 是 ， 这 的 的 确 确 是 架设 一 个 少数 人 具有 连接 权 的 Git 服务 的 全 部 一 一 只 要 在 服务 器 上 加 入 可 以 
SSH 接 入 的 帐号 ， 然 后 把 纯 仓 库 放 在 大 家 都 有 读 写 权 限 的 地 方 。 一 切 都 做 好 了 ， 无 须 更 多 。 

















































































































下 面 的 几 节 中 ， 你 会 了 解 如 何 扩展 到 更 复杂 的 设 定 。 这 些 内 容 包含 如 何 避 免 为 每 一 个 用 户 建立 一 个 账户 ， 给 
仓库 添加 公共 读 取 权 限 ， 架 设 网 页 界面 ， 使 用 Gitosis 工具 等 等 。 然 而 ， 只 是 和 几 个 人 在 一 个 不 公开 的 项 
上 合作 的 话 ， 仅 仅 是 一 个 SSH 服务 器 和 纯 仓 库 就 足够 了 ， 请 牢记 这 一 点 。 
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4.2.2 小 型 安装 




















































































































如 果 设 备 较 少 或 者 你 只 想 在 小 型 的 开发 团队 里 尝试 Git ， 那 么 一 切 都 很 简单 。 架 设 Git 服务 最 复杂 的 方面 
之 一 在 于 账户 管理 。 如 果 需 要 仓库 对 特定 的 用 户 可 读 ， 而 给 另 一 部 分 用 户 读 写 权限 ， 那 么 访问 和 许可 的 安排 就 
比较 困难 。 























































































































SSH 连接 


如 果 已 经 有 了 一 个 所 有 开发 成 员 都 可 以 用 SSH 访问 的 服务 器 ， 架 设 第 一 个 服务 器 将 变 得 异常 简单 ， 几 乎 什 
么 都 不 用 做 (正如 上 节 中 介绍 的 那样 ，。 如 果 需 要 对 仓库 进行 更 复杂 的 访问 控制 ， 只 要 使 用 服务 器 操作 系统 的 
问 许可 机 制 就 行 了 。 

如 果 需 要 团队 里 的 每 个 人 都 对 仓库 有 写 权 限 ， 又 不 能 给 每 个 人 在 服务 器 上 建立 账户 ， 那 么 提供 SSH HEB 
是 唯一 的 选择 了 。 我 们 假设 用 来 共享 仓库 的 服务 器 已 经 安装 了 SSH 服务 ， 而 且 你 通过 它 访 问 服务 器 。 

有 好 几 个 办 法 可 以 让 团队 的 每 个 人 都 有 访问 权 。 第 一 个 办 法 是 给 每 个 人 建立 一 个 账户 ， 直截了当 但 过 于 每 
Hi o RAST adduser 并 且 给 所 有 人 设 定 临 时 密码 可 不 是 好 玩 的 。 

第 二 个 办 法 是 在 主机 上 建立 一 个 git 账户 ， 让 每 个 需要 写 权 限 的 人 发 送 一 个 SSH 公 钥 ， 然 后 将 其 加 入 sit 
账户 的 ~/.ssh/authorized_keys 文件 。 这 样 一 来 ， 所 有 人 都 将 通过 sit 账户 访问 主机 。 这 丝 党 不 会 影响 提交 的 数 
据 一 一 访问 主机 用 的 身份 不 会 影响 commit 的 记录 。 

另 一 个 办 法 是 让 SSH 服务 器 通过 某 个 LDAP 服务 ， 或 者 其 他 已 经 设 定好 的 集中 授权 机 制 ， 来 进行 授权 。 只 
要 每 个 人 都 能 获得 主机 的 shell 访问 权 ， 任 何 可 用 的 SSH 授权 机 制 都 能 达到 相同 效果 。 
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4.3 生成 SSH 2A 


























话 虽 如 此 ， 大 多 数 cit 服务 器 使 用 SSH 公 钥 来 授权 。 为 了 得 到 授权 ， 系 统 中 的 每 个 没有 公 角 用户 都 得 生成 
一 个 新 的 。 该 过 程 在 所 有 操作 系统 上 都 差不多 。 首先 ， 确 定 一 下 是 否 已 经 有 一 个 公 钥 了 。SSH 公 角 默认 储存 































































































































































































在 账户 的 ~/.ssh 目录 。 进 入 那里 并 查看 其 内 容 ， 有 没有 公 钥 一 目 了 然 : 
$ cd ^/.ssh 

$ 1s 

authorized keys2 id dsa known hosts 

config id dsa.pub 





关键 是 看 有 没有 用 文件 名 和 文件 名 .pub 来 命名 的 一 对 文件 ， 这 个 文件 名 通常 是 id dsa 或 者 id nsa 
.pub 文件 是 公 钥 ， 男 一 个 文件 是 密 钥 。 假 如 没有 这 些 文件 (或 者 干脆 连 .ssh 目录 都 没有 ) ， 你 可 以 用 ssh- 
keygen 的 程序 来 建立 它们 ， 该 程序 在 Linux/Mac 系统 由 SSH 包 提供 ， 在 Windows 上 则 包含 在 MSysGit 包 


































































































































































































$ ssh-keygen 

Generating public/private rsa key pair. 

Enter file in which to save the key (/Users/schacon/.ssh/id rsa): 

Enter passphrase (empty for no passphrase): 

Enter same passphrase again: 

Your identification has been saved in /Users/schacon/.ssh/id rsa. 

Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub. 

The key fingerprint is: 

43:c5:5b:5f:b1:£1:50:438:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop. local 
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EC ECR (HI 





EN 


上 认 保存 公 钥 的 位 置 (.ssh/id_rsa) ， 然 后 它 会 让 你 重 
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时 候 输入 密码 ， 可 以 留 空 。 
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ji 



































$ cat ^/.ssh/id rsa.pub 

ssh-rsa AAAAB3NzaClyc2EAAAABIWAAAQEAK1 0UpkDHrfHY17SbrmT IpNLTGK9T jom/BWDSU 
GP1-nafzlHDTYW7hdI4yZ5ew18JHAJW9 jbhUFrviQzM7x1ELEV£4h91FX5QVkbPppSwg0cda3 
Pbv7k0dJ/MTyB1WXFCR+HAo3FXRi tBqxi X1 nKhXpHAZsMc i Lq8V6RjsNAQwdsdMFvS1VK/7XA 
t3FaoJoAsncM1Q9x5*3V0Ww68/eIFmblzuUFlJjQJKprrX88XypNDv jYNby6vw/PbOrwert/En 
mZ+AW40ZPnTPI89ZPmVMLuayrD2cE86Z/i18b+gw3r3+1nKatmIkjn2sold01QraT1MqVSsbx 
NrRFi9wrf+M7Q== schacon@agadorlaptop. local 














现在 ， 所 有 做 过 这 一 步 的 用 户 都 得 把 它们 的 公 钥 给 你 或 者 Git 服务 器 的 管理 
j 公 钥 机 制 ) 。 他 们 只 需要 复制 .put 文件 的 内 容 然 后 e-email 之 。 公 钥 的 样子 大 致 如 下 : 











4.4 节 架设 服务 器 








果 不 想 在 使 用 公 钥 的 





& (假设 SSH 服务 被 设 定 为 使 




















关于 在 多 个 操作 系统 上 设立 相同 SSH 公 钥 的 教程 ， 可 以 在 Github 有 关 SSH 公 钥 的 向 导 中 找到 : http: 














//github.com/guides/providing-your-ssh-key ° 


4.4 架设 服务 器 























现在 我 们 过 一 边 服务 器 端 架设 SSH 访问 的 流程 。 本 例 将 使 用 authorized keys 7712] 
假定 使 用 类 似 Ubuntu 这 样 的 标准 Linux 发 行 版 。 首 先 ， 创 建 一 个 














WP c 











(译注 ;在 用 户 的 主 目录 下 ) 。 

















$ sudo adduser git 
$ su git 

$ cd 

$ mkdir .ssh 




















接 下 来 ， 把 开发 者 的 SSH 公 角 添加 到 这 个 用 户 的 authorized keys 文件 
公 钥 并 存 到 了 临时 文件 里 。 重 复 一 下 ， 公 钥 大 致 看 起 来 是 这 个 样子 : 






























































$ cat /tmp/id rsa.john.pub 

ssh-rsa AAAAB3NzaClyc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L 
ojG6rs6hPB09j9R/T17/x41hJAOF3FR1rP6kYBRsWj2aThGw6HXLm9/5z ytK6Ztg3RPKK--4k 
Yjh6541NYsnEAZuXzOjTTyAUfrtU3Z5E003C40x036HOrf IFIKKI9MAQLMdpGWIGYEIgS9Ez 
Sdfd8AcCIicTDWbqLAcUAUpkaX8KyG1LwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc-myiv 
O7 TCUSBdLQ1gMVOFq112uPWQOKkOWQAHukEOmf jy2.jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq 
dAv8JggJICUvax2T9va5 gsg-keypair 




















只 要 把 它们 加 入 _ authorized keys 文件 〈 译 注 : 本 例 加 入 到 了 文件 


$ cat /tmp/id rsa.john.pub >> ~/.ssh/authorized_keys 
$ cat /tmp/id rsa.josie.pub >> ^/.ssh/authorized keys 
$ cat /tmp/id rsa.jessica.pub >> ~/.ssh/authorized_keys 








给 用 户 授权 。 我 们 i 






































创建 一 个 .ssh 












































Xll zx 














1。 假设 你 通过 e-mail 收 到 了 几 个 
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现在 可 以 使 用 














$ cd /opt/git 

$ mkdir project.git 
$ cd project.git 

$ git --bare init 


这 时 ，Join，Josie 或 者 Jessica 就 可 以 把 
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--bare 选项 运行 git init 来 设 定 一 个 空仓 库 ， 





> 加 为 远程 
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JE, 
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Ls 


传 到 仓库 里 了 。f 


Zz 








ve 














au 























不 妨 


P. gitserver 





gitserver +5 向 该 3 


# 在 John 的 电脑 上 
cd myproject 
init 


add . 


git 
git 
git commit -m 
git 


RA eer er See eh see 


git 














作为 git 








FE 机 ， 那 么 以 下 


'initial commit' 


push origin master 

















这 样 ， 








Lith ABS) Rae AF 














FE 意 的 是 ， 


EIS tht 


每 次 添加 一 个 3 


A 








HH 
仓库 所 在 的 主机 名 





这 会 初始 化 一 个 不 包含 


推送 一 个 分 文 ， 从 而 
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录 的 仓库 。 

















E TS 




















都 需要 通过 shell 登入 了 














NE 


机 





创建 





Taras 
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一 个 版 本 的 工程 
一 个 纯 仓库 。 我 作 
































。 如 





从 











户 和 





























这 些 命令 都 是 可 


变 得 很 简单 : 











vim README 


ep ES R ve 








用 这 个 方法 可 
作为 一 个 额外 
相关 。 把 它 设 为 





























git 


git push origin master 


以 很 快捷 的 为 少数 几 个 
的 防范 措施 ， 你 可 以 用 
JP'XE ABS 



































点 ， 需 要 指明 





JAHJA shell 是 git-shell , 





NNOD ng 


$ sudo vim /etc/passwd 





在 文件 末 





git clone git@gitserver:/opt/git/project.git 


git commit -am 'fix for the README file' 








remote add origin git@gitserver:/opt/git/project.git 
































的 git-shell 


KA DZS PATE 


个 可 读 写 的 





Git 服务 。 


ET git 








Hi 


简单 
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JP UP BE 





shel 








ges 











必 ， 你 应 该 能 找到 


似 这 样 的 





TJ 


git:x:1000:1000::/home/git:/bin/sh 





H bin/sh 改 为 /usr/bin/git-shell 

















whic 


( 





或 者 用 








git:x:1000:1000: :/home/git:/usr/bin/git-shell 
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有 主机 正常 的 s 

















bash 或 者 csh。 你 可 能 得 
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ASTA 


ne 








机 ， 




















日 在 DNS 





XE 











Iu 


JRI 
11 访问 

































































h git-shell 





























编辑 /etc/passw 





























动 限 制 在 仅 与 Git 
权 。 为 了 实现 这 一 
文件 : 




















Scott Chacon Pro Git 4.5 节 公共 访问 












































现在 eit 用 户 只 能 用 SSH 连接 来 推送 和 获取 Git 仓库 ， 而 不 能 直接 使 用 主机 shell o KIERA, MÈ 
看 到 下 面 这 样 的 拒绝 信息 : 






















































































$ ssh git@gitserver 
fatal: What do you think I am? A shell? (你 以 为 我 是 个 哈 ? shelly ? ) 
Connection to gitserver closed. (gitserver 连接 已 断 开 。) 


4.5 公共 访问 
































名 的 读 取 权 限 该 怎么 实现 呢 ? 也 许 除 了 内 部 私有 的 项 目 之 外 ， 你 还 需要 托管 一 些 开源 项 目 。 换 或 你 使 用 
自动 化 的 服务 器 来 进行 编译 ， 或 者 一 些 经 常 变化 的 服务 器 群 组 ， 而 又 不 想 整 天 生成 新 的 SSH 密 钥 一 一 总 
之 ， 你 需要 简单 的 匿名 读 取 权 限 。 
或 许 对 小 型 的 配置 来 说 最 简单 的 办 法 就 是 运行 一 个 静态 web 服务 ， 把 它 的 根 目 录 设 定 为 Git 仓库 所 在 的 位 











































































































































































































































































































































































































置 ， 然 后 开启 本 章 第 一 节 提 到 的 post-update 挂钩。 这 里 继续 使 用 之 前 的 例子 。 假 设 仓 库 处 于 /opt/git HX, 
主机 上 运行 着 Apache 服务 。 重 | ， 任 何 web 服务 程序 都 可 以 达到 相同 效果 作为 范例 ， 我 们 将 用 一 些 
基本 的 Apache 设 定 来 展示 大 体 需要 的 步骤。 

先 ， 开 启 挂钩 : 














$ cd project.git 
$ mv hooks/post-update.sample hooks/post-update 
$ chmod a*x hooks/post-update 








H 








假如 使 用 的 Git 版 本 小 于 1.6, AB mv 命令 可 以 省 略 一 一 Git 是 从 较 晚 的 版 本 才 开 始 在 挂钩 实例 的 经 
加 .sample 后 缀 名 的 。 
post-update 挂钩 是 做 什么 的 呢 ? 其 内 容 大 致 如 下 : 



























































$ cat .git/hooks/post-update 
#!/bin/sh 


exec git-update-server-info 



































意思 是 当 通 过 SSH 向 服务 器 推送 时 ，Git 将 运行 这 个 命令 来 更 新 HTTP 获取 所 需 的 文件 。 
LW, Æ Apache 配置 文件 中 添加 一 个 _ VirtualHost 条 目 ， 把 根 文件 (EYE: DocumentRoot 参数 ) E 
为 cit 项 目的 根 目录 。 假 定 DNS 服务 已 经 配置 好 ， 会 把 .gitserver 发 送 到 任何 你 所 在 的 主机 来 运行 这 些 : 







































































































































































<VirtualHost *:80> 
ServerName git.gitserver 
DocumentRoot /opt/git 
<Directory /opt/git/> 
Order allow, deny 
allow from all 
</Directory> 


</VirtualHost> 
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另外 ， 需 要 把 /opt/eit 目录 的 Unix 用 户 组 设 定 为 wwedata ， 这 样 web 服务 才 可 以 读 取 仓 库 内 容 ， 因 为 
Apache 运行 CGI 脚本 的 模块 (默认 ) 使 用 的 是 该 用 户 : 





$ chgrp -R www-data /opt/git 











重启 Apache 之 后 ， 就 可 以 通过 项 目的 URL 来 克隆 该 目录 下 的 仓库 了 。 
































$ git clone http://git.gitserver/project.git 























这 一 招 可 以 让 你 在 几 分 钟 内 为 相当 数量 的 用 户 架 设 好 基于 HTTP 的 读 取 权 限 。 另 一 个 提供 非 授权 访问 的 简单 
方法 是 开启 一 个 Git 守护 进程 ， 不 过 这 将 要 求 该 进程 的 常 驻 一 一 下 一 节 将 是 想 走 这 条 路 的 人 准备 的 。 














4.6 网 页 界面 GitWeb 



































如 今 我 们 的 项 目 已 经 有 了 读 写 和 只 读 的 连接 方式 ， 也 许 应 该 再 架设 一 个 简单 的 网 页 界面 使 其 更 加 可 视 化 。 
AE, Git 自 带 了 一 个 叫做 GitWeb 的 CGI 脚本 。 你 可 以 在 类 似 http://git.kernel.org 这 样 的 站 点 找到 
GitWeb 的 应 用 实例 ( 见 图 4.1) 。 





























/pub/scm / git/git.git / summary 333 git | 


summary | shortiog | log | comen | comenitestt | ree (comma WW} search: 





description The core git plumbing 

owner Junio C Hamano 

last change Fri, 20 Feb 2009 07:44:07 +0000 
URL git//git kernel.org/pub/scm/git/git. git 


http://www.kernel.org/pub/scm/git/git git 

shortlog 

33 hours ago Junio C Hamano Merge branch ‘maint’ master) comet ! gomma | teg | cd ot 
34 hours ago Matthieu Moy More friendly message when locking the index fails. maint) coment | commas | red | sorot 
34 hours ago Matthieu Moy Document git blame --reverse. genes | Om | es | enapenot 
34 hours ago Marcel M. Cary gitweb: Hyperlink multiple git hashes on the same commi ... 0070 ! 0000321 ! top | sososoot 
34 hours ago Johannes Schindein system path(): simplify using strip path suffix(), ... cov | qom | Poe | a 
34 hours ago Johannes Schindebn Introduce the function strip path suffix() oco | GTS | veg | gnapthot 
2daysago Todd Zullinger Documentation: Note file formats send-email accepts foco | oor | ees | snapshot 
2daysago Junio C Hamano Merge branch ‘maint’ Soy | oomen | tree | OO 
2daysago Junio C Hamano tests: fix “export Varsvar SS | Gea | ves | Ec 
2days ago Lars Noschinsk filter-branch -d: Export GIT DIR earlier fpc | comma | ves | snapinot 
2daysago Jay Soffian disallow providing multiple upstream branches to rebase ... COMM | 0909321 | ee | miana 
2daysago Michael Spang Skip timestamp differences for diff -no-index COTS | 9221 | res | ARAOS 
2days ago Junio C Hamano git-svn: fix parsing of timestamp obtained from svn Somes | om | ves | soapsnet 
2daysago Marcel M. Cary gitweb: Fix warnings with override permitted but no ... ore | commas | oe | ao Ot 
2daysago Gerrit Pape Documentation/git-push: —all, —mirror, —tags can ... £507) | mS | vec | OE 
2days ago Thomas Ras! bash completion: only show ‘log --merge' if merging comms | COMMAS | tees | snacsnot 


图 4.1: 基于 网 页 的 GitWeb AP Ra 




















如 果 想 知道 项 目的 GitWeb 长 什么 样 ，Git 自 带 了 一 个 命令 ， 可 以 在 类 似 lighttpd 或 webrick 这 样 轻 量 级 的 
服务 器 程序 上 打开 一 个 临时 的 实例 。 在 Linux 主机 上 通常 都 安装 了 lighttpd ， 这 时 就 可 以 在 项 目 目录 里 输入 
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git instaweb 来 运行 


lighttpd 以 外 的 程序 来 启用 






































可 以 通过 它 

















git instaweb, 








$ git instaweb --httpd=webrick 
[2009-02-21 10:02:21] INFO WEBrick 1.3.1 
[2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universa 





p 








书 。 如 果 使 用 的 是 Mac , Leopard 预 装 了 Ruby， 所 以 webrick MIKE BFA 


的 --httpd 选项 来 实现 。 


1-darwin9.0] 


























这 会 在 1234 m 


要 使 用 








E Fi 
相同 命令 的 --stop 选项 就 好 了 : 
































$ git instaweb --httpd=webrick --stop 




















个 HTTPD 服务 ， 随 之 在 浏览 器 


























显示 该 页 。 简 单 的 很 。 


4.6 节 网 页 界面 GitWeb 


























T 














需要 关闭 服务 的 时 候 ， 只 


























































































































如 果 需 要 为 团队 或 者 某 个 开源 项 目 长 期 的 运行 web 界面 ， 那 么 CGI 脚本 就 要 由 正常 的 网 页 服务 来 运行 。 一 
BE Linux 发 行 版 可 以 通过 apt 或 yum 安装 一 个 叫做 gitweb 的 软件 包 ， 不妨 首先 尝试 一 下 。 我 们 将 快速 的 介 
绍 一 下 手动 安装 GitWeb 的 流程 。 首 先 ， 你 需要 Git 的 源码 ， 其 中 带 有 GitWebp， 并 能 生成 CGI 脚本 : 

















$ git clone git://git.kernel.org/pub/scm/git/git.git 
$ cd git/ 
$ make GITWEB PROJECTROOT-"/opt/git" N 
prefix-/usr gitweb/gitweb.cgi 
$ sudo cp -Rf gitweb /var/www/ 


N 


注意 通过 指定 GITWEB PROJECTROOT 
为 此 添加 一 个 VirtualHost: 














HES IPA A 
告诉 编译 令 


fin Gi 
































<VirtualHost *:80> 

ServerName gitserver 

DocumentRoot /var/www/gitweb 

<Directory /var/www/gitweb> 
Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch 
AllowOverride A11 
order allow,deny 
Allow from all 
AddHandler cgi-script cgi 


DirectoryIndex gitweb.cgi 






































t 仓库 的 位 置 。 







































































A, tk Apache 来 提供 脚本 的 CGI, 








































































































</Directory> 
</VirtualHost> 

不 难 想 象 ，GitWeb 可 以 使 用 任何 兼容 CGI 的 网 页 服务 来 运行 ， 如 果 仿 向 使 用 其 他 的 (译注: 这 里 指 
Apache 以 外 的 服务 ) ， 配 置 也 不 会 很 麻烦 。 现 在 ， 通 过 http://gitserver 就 可 以 在 线 访问 仓库 了 ， 在 
http://git.server 上 还 可 以 通过 HTTP 克隆 和 获取 仓库 的 内 容 。 Again, GitWeb can be served with any 














CGI capable web server; if you prefer to use somet 








hing else, it shouldn' t 





be difficult to set up. 


At this point, you should be able to visit http://gitserver/ to view your repositories online, 


and you can use http://git.gitserver to clone and fetch your repositories over HTTP. 
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4.7 权限 管理 器 Gitosis 
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把 所 有 用 户 的 公 钥 保存 在 authorized keys 文件 的 做 法 只 能 暂时 奏效 。 当 用 户 数量 到 了 几 百 人 的 时 候 ， 它 会 变 
成 一 种 痛苦 。 每 一 次 都 必须 进入 服务 器 的 shel1， 而 且 缺 少 对 连接 的 限制 一 一 文件 里 的 每 个 人 都 对 所 有 项 目 拥 
有 读 写 权限 。 

现在 ， 是 时 候 向 广泛 使 用 的 软件 Gitosis 求救 了 。Gitosis 简单 的 说 就 是 一 套用 来 管理 authorized keys X 








































































































































































































你 只 需要 设 定好 某 个 项 目 ， 然 后 推送 ，Gitosis 就 会 随 之 改变 服务 器 设 定 ， 酷 吧 ? 
















































































































































































python-setuptools: 


$ apt-get install 


python-setuptools 





接 下 来 ， 从 项 

















主页 克隆 和 安装 Gitosis: 











$ git clone git://eagain.net/gitosis.git 


$ cd gitosis 


$ sudo python setup.py install 


这 会 安装 几 个 Gitosis 





Xn 





































































































$ 1n -s /opt/git /home/git/repositories 


Gitosis 将 为 我 们 管理 公 钥 ， 所 以 当前 的 文件 需要 删除 ， 以 后 再 
authorized keys 文件 9 现在 ， 把 authorized_keys 文 件 移 走 : 








的 服 





rn 


























件 和 实现 简单 连接 限制 的 脚本 。 最 有 意思 的 是 ， 该 软件 用 来 添加 用 户 和 设 定 权 限 的 界面 不 是 网 页 ， 而 是 一 个 特 
殊 的 Git 仓库 。 

Gitosis 的 安装 算 不 上 傻瓜 化 ， 不 过 也 不 算 太 难 。 用 Linux 服务 器 架设 起 来 最 简单 一 一 以 下 例子 
器 使 用 Ubuntu 8.10 系统 。 
Gitosis 需要 使 用 部 分 Python 工具 ， 所 以 首先 要 安装 Python AY setuptools 包 ， 在 Ubuntu 


务 


为 


有 的 本 机 文件。 现在 ，Gitosis 想 把 它 的 仓库 放 在 /home/git， 倒 也 可 以 。 不 过 我 
们 的 仓库 已 经 建立 在 /opt/git 了 ， 这 时 可 以 创建 一 个 文件 连接 ， 而 不 用 从 头 开始 重新 配置 : 











lil 
pap 








Br JU ZS 4A , 让 Gitosis 























自动 控 








ilg 
































$ mv /home/git/.ssh/authorized keys /home/git/.ssh/ak.bak 


€ 


然后 恢 













































































git:x:1000:1000::/home/git:/usr/bin/git-shell 


SE 


恢复 成 : 


git:x:1000:1000: :/home/git:/bin/sh 
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制 





复 ‘sit’ HP shell, 假设 之 前 把 它 改 成 了 git-shell 命令 。 其 他 人 仍然 不 能 通过 它 来 登录 系 
统 ， 不 过 这 次 有 Gitosis 帮 有 我 们 实现 。 所 以 现在 把 /etc/passwd 文件 的 这 一 行 








Scott Chacon Pro Git 4.7 节 权限 管理 器 Gitosis 












































现在 就 可 以 初始 化 Gitosis 了 。 需 要 通过 自己 的 公 铀 来 运行 sitosis-init。 如 果 公 钥 不 在 服务 器 上 ， 则 必须 
复制 一 份 






































$ sudo -H -u git gitosis-init < /tmp/id dsa.pub 
Initialized empty Git repository in /opt/git/gitosis-admin.git/ 
Reinitialized existing Git repository in /opt/git/gitosis-admin.git/ 




















> 









































这 样 该 公 钥 的 拥有 者 就 能 修改 包含 着 Gitosis 设置 的 那个 Git 仓库 了 。 然 后 手动 将 这 个 新 的 控制 仓库 中 的 
post-update 脚本 加 上 执行 权限 。 






























































$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update 





























Ini 























5 事 俱 备 了 。 如 果 设 定 过 程 没 出 什么 差错 ， 现 在 可 以 试 一 下 用 初始 化 Gitesis 公 钥 的 拥有 者 身份 SSH 进 服 
务 器 。 看 到 的 结果 应 该 和 下 面 类 似 : 













































































$ ssh git@gitserver 
PTY allocation request failed on channel 0 
fatal: unrecognized command 'gitosis-serve schacon@quaternion' 


Connection to gitserver closed. 





























说 明 Gitosis 认 出 了 该 用 户 的 身份 ， 但 由 于 没有 运行 任何 Git 命令 所 以 它 切断 了 连接 。 所 以 ， 现 在 运行 一 
个 确 一 克隆 Gitosis 的 控制 仓库 : 






























































# 在 自己 的 电脑 上 


$ git clone git@gitserver:gitosis-admin.git 

















得 到 一 个 名 为 gitosis-admin 的 目录 ， 主 要 由 两 部 分 组 成 : 




















$ cd gitosis-admin 
$ find . 
./gitosis.conf 
./keydir 
./keydir/scott.pub 















































gitosis.conf 文件 是 用 来 设置 用 户 、 仓 库 和 权限 的 控制 文件 。keydir 目录 则 是 保存 所 有 有 共有 访问 权限 用 户 
公 钥 的 地 方 一 一 每 人 一 个 。 你 keydir 中 的 文件 名 (前 例 中 的 scott.pub) 应 该 有 所 不 同 Gitosis 从 使 用 
gitosis-init 脚本 导入 的 公 钥 尾部 的 描述 中 获取 该 名 。 
看 一 下 gitosis.conf 的 内 容 ， 它 应 该 只 包含 与 刚刚 克隆 的 gitosis-admin 相关 的 信息 : 



















































































T 
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$ cat gitosis.conf 


[gitosis] 


[group gitosis-admin] 
writable - gitosis-admin 


members - scott 














n 
zE ME 
z 


3 














jp: scott 一 一 初始 化 Gitosis 


门 添 加 一 个 新 的 项 目 


公 钥 的 拥有 者 
我 们 将 添加 一 个 名 为 mobile f 





能 访问 gi 
TE, fex 





ES 
现在 

















o 












































tosis-admin 项 



























































是 系统 中 的 只 








mt 


'scott' 





[os 
叫做 iphone project. 的 新 项 


我 
及 他 们 需要 访问 权限 的 项 目 。 由 了 


始 : 


















































[group mobile] 
writable - iphone project 


members - scott 





















































一 旦 修改 ] 有 











WIA, 





gitosis-admin Jil 





AN 


$ git commit -am 'add iphone_project and mobile group' 


[master]: created 8962da8: "changed name" 

l files changed, 4 insertions(+), 0 deletions(-) 
$ git push 
5, done. 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (3/3), 272 bytes, 
Total 3 (delta 1), reused 0 (delta 0) 
To git@gitserver:/opt/git/gitosis-admin. git 


fb27aec. 


Counting objects: 


done. 


.8962da8 master -> master 























LA 
在 服务 


时 iphone project 的 推送 需要 在 本 地 的 版 本 把 
器 上 创建 纯 仓 库 的 麻烦 就 是 历史 了 一 一 Gitosis 





服务 器 添加 为 


a 
ZS. 





第 一 次 向 
动 为 新 项 
们 : 















































$ git remote add origin gitegitserver:iphone project.git 

$ git push origin master 

Initialized empty Git repository in /opt/git/iphone project.git/ 
3, done. 

Writing objects: 100% (3/3), 230 bytes, 
Total 3 (delta 0), reused 0 (delta 0) 


To gitegitserver:iphone project.git 


Counting objects: 


done. 


* [new branch] master -> master 








nM 
L^ 
Ca 








FUE 


ZN 


























注意 到 路 径 被 忽略 ] 


o 


(加 上 它 反 而 没 用 ) 个 冒号 加 项 目的 4 














Hgi 
































IF, RIE 


在 第 一 


E 送 至 服务 器 才能 使 之 生效 : 


一 个 remote 然后 推 
到 推 


次 i 


里 罗列 好 
它 加 成 


^H 














H 














Y —— Gitosis 会 为 你 找到 项 




















H 














要 和 朋友 们 共同 在 一 个 项 作 ， 就 得 重 3 
添加 到 ^/.ssh/authorized keys 文件 末端 ， 而 是 在 keydir 
用 户 的 称呼 。 现 在 我 们 为 John, 








SRD 
目录 为 每 
















































































gitosis.conf 文件 


80 





0 他 们 的 公 钥 。 不 过 这 次 不 月 
个 公 钥 添加 一 个 文件 。 文 件 的 命 
Josie 和 Jessica JJ 4A: 











在 服务 器 上 一 个 一 个 了 


Scott Chacon Pro Git 
























































| 
iH 











送 。 从 此 
动 创 


























送 的 时 候 




















目的 位 








手动 
RE TE 














ZR 
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$ cp /tmp/id rsa.john.pub keydir/ john. pub 
$ cp /tmp/id rsa.josie.pub keydir/josie.pub 
$ cp /tmp/id rsa.jessica.pub keydir/jessica.pub 





N 





4r 




















然后 把 他 们 都 加 进 “mobile” 团队 ， 让 他 们 对 iphone project H 








BUR: 


an 
3 

















[group mobile] 
writable - iphone project 


members = scott john josie jessica 


























c 














如 果 你 提交 并 推送 这 个 修改 ，p 
Gitosis 也 具有 简单 的 访问 控制 

















个 用 户 将 同时 具有 该 项 目的 读 写 权限 。 
功能 。 如 果 想 让 John 只 有 读 权限 ， 可 以 这 样 做 : 

























































































[group mobile] 
writable - iphone project 


members - scott josie jessica 


[group mobile ro] 
readonly - iphone project 


members - john 






























































现在 John 可 以 克隆 和 获取 更 新 ,， 但 Gitosis 不 会 允许 他 向 项 目 推送 任何 内 容 。 这 样 的 
随意 多 个 ， 每 一 个 包含 不 同 的 用 户 和 项 目 。 甚 至 可 以 指定 某 个 组 为 成 员 ， 来 继承 它 所 有 的 成 
如 果 出 现 了 什么 问题 ， 把 loglevel=DEBUG 加 入 到 [gitosis] 部 分 或 许 有 帮助 GEE: 把 日 志 设 置 到 调试 级 
别 ， 记 录 更 详细 的 信息 ) 。 如 果 你 一 不 小 心 搞 错 了 配置 ， 失 去 了 推送 权限 ， 可 以 手动 修改 服务 器 上 的 /nome/ 
git/.gitosis 文件 一 一 Gitosis 从 该 文件 读 取 信息 。 一 次 推送 会 把 gitosis.conf 保存 在 服务 器 上 。 如果 你 手动 
编辑 该 文件 ， 它 将 在 你 下 次 向 gitosis-admin 推送 之 前 它 将 保持 原样 。 





可 以 有 尽 可 能 
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um B 























































































































































































































































































































4.8 Git 进程 


















































公共 ， 非 授权 的 只 读 访 问 要 求 我 们 在 HTTP 协议 的 基础 上 使 用 Git 协议 。 主 
效 ， 进 而 比 HTTP 协议 更 迅速 ， 所 以 它 能 节省 很 多 时 间 。 
申 一 下 ， 这 一 点 只 适用 于 非 授 权 、 只 读 的 访问 。 如 果 在 防火 墙 之 外 的 服务 器 上 ， 该 服务 的 使 用 应 该 局 限于 
公 诸 于 世 的 项 目 。 假 如 是 在 防火 墙 之 内 ， 它 也 可 以 用 于 具有 大 量 参 与 人 员 或 者 主机 (长 期 整合 资源 或 编译 的 服 
ae) 的 只 读 访问 的 项 目 ， 可 以 省 去 为 逐一 添加 SSH 公 钥 的 麻烦 。 
无 论 哪 种 情况 ，Git 协议 的 设 定 都 相对 简单 。 基 本 上 ， 只 要 以 长 期 守护 进程 的 形式 运行 该 命令 : 
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iz 











在 于 速度 。Git 协议 更 为 高 
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idi 





























git daemon --reuseaddr --base-path-/opt/git/ /opt/git/ 
















































































--reuseaddr 使 得 服务 无 须 等 到 旧 的 连接 尝试 过 期 以 后 再 重启 ，--base-path 选项 使 得 克隆 项 目的 时 候 不 用 给 出 
完整 的 路 径 ， 而 最 后 面 的 路 径 告诉 Git 进程 导出 仓库 的 位 置 。 假 如 有 防火 墙 ， 则 需要 为 该 主机 的 9418 端 
打 个 允许 通信 的 洞 。 
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有 几 个 不 同 的 办 法 可 以 让 该 进程 长 期 驻 留 ， 取 决 于 不 同 的 操作 系统 。 在 Ubuntu 主机 上 ， 可 以 用 Upstart 
脚本 来 完成 。 于 是 ， 在 下 面 这 个 文件 
/etc/event.d/local-git-daemon 
加 入 该 脚本 内 容 : 
start on startup 
stop on shutdown 
exec /usr/bin/git daemon \ 
--user-git --group-git \ 
--reuseaddr \ 
--base-path-/opt/git/ \ 
/opt/git/ 
respawn 
出 于 安全 考虑 ， 强 烈 建议 用 一 个 对 仓库 只 有 读 取 权限 的 用 户 身 份 来 运行 该 进程 一 一 只 需要 简单 的 新 创建 一 个 
git-ro 用 户 (HH: 并 将 它 对 仓库 的 权限 设 为 只 读 ) ， 用 它 来 运行 进程 。 为 了 简化 ， 下 面 我 们 将 依旧 使 用 运行 
了 Gitosis 的 ‘git’ 用 户 。 
重启 主机 的 时 候 ，Git 进程 会 自行 启动 ， 一 旦 关闭 了 也 会 自行 重启 。 要 不 重启 就 开启 它 ， 可 以 运行 这 个 命 
A. 
L: 
initctl start local-git-daemon 
在 其 他 系统 上 ， 或 许 应 该 使 用 xinetd, sysinit 的 一 个 脚本 ， 或 者 其 他 的 只 要 能 让 那个 命令 进程 化 和 可 
然后 ， 必 须 告 诉 Gitosis 服务 那些 仓库 允许 基于 Git 协议 的 非 授权 访问 。 如 果 为 每 一 个 仓库 设立 的 
节 段 ， 就 可 以 指定 想 让 Git 进程 给 予 可 读 权限 的 仓库 。 假 如 要 允许 通过 Git 协议 访问 前 面 的 iphone 项 目 
可 以 把 如 下 内 容 加 到 gitosis.cont 文件 的 结尾 : 
[repo iphone project] 
daemon - yes 
在 提交 和 推送 完成 以 后 ， 运 行 中 的 进程 将 开始 相应 所 有 能 访问 主机 9418 端口 的 人 发 来 的 项 目 请 求 。 
假如 不 想 使 用 Gitosis， 而 又 想 架设 一 个 Git 协议 进程 ， 则 必须 为 每 一 个 想 使 用 Git 进程 的 项 目 运行 如 下 
命令 : 


$ cd /path/to/project.git 


$ touch git-daemon-export-ok 

















该 文件 (译注: 指 空 文件 git-deamon-export-ok) 告诉 Git 人 允许 对 该 项 目的 非 授 权 访问 。 


Gitosis 还 和 角 
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B| GitWeb 显示 哪些 项 目 
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H 




















7 


L, 











在 /etc/gitweb.conf 添加 如 下 内 








BS 


容 : 





Scott Chacon Pro Git 


$projects list - "/home/git/gitosis/projects. list"; 


$projectroot = "/home/git/repositories"; 


$export_ok = "git-daemon-export-ok"; 


Ogit base url list = ('git://gitserver') 












































通过 在 Gitosis 的 设置 文件 里 添加 或 删除 gitweb WE, 








就 能 控制 GitWeb 允许 用 户 浏览 哪些 项 目 
































我 们 想 让 iphone 项 目 在 GitWeb 里 出 现 ， 把 repo 的 设 定 改 成 下 面 的 样子 : 

















[repo iphone project] 


daemon = yes 


gitweb - yes 
































如 有 果 现 在 提交 和 推送 该 项 目 ，GitWeb 会 自动 开始 展示 我 


























4.9 Git 托管 服务 


























想 经 历 自己 架设 Git 服务 器 的 麻烦 ， 网 络 上 有 几 个 专业 的 仓库 托管 服务 可 供 选 择 。 这 档 




















将 在 这 一 节 介 绍 一 下 在 GitHub 建立 账户 和 开启 新 项 目的 过 程 。 为 你 提供 一 个 使 
GitHub 是 到 目前 为 止 最 大 的 开源 Git 托管 服务 ， 并 且 
一 ， 所 以 你 可 以 在 一 个 站 点 同时 保存 开源 和 商业 代码 。 事 实 上 ， 本 书 正 是 私下 使 用 


而 本 书 的 翻译 也 是 在 GitHub 上 进行 公共 合作 的 ) e 


























目前 ， 


















































们 的 iphone 项 目 。 







































































的 建立 通常 比较 省 时 ， 方 便 项 目的 启动 ， 而 














4.9 节 Git 


























不 涉及 服务 其 的 维护 和 监控 。 即 使 内 部 创建 并 运行 














2 
,的 服务 器 ， 为 开源 的 代码 使 用 一 个 公共 托管 站 点 还 是 有 好 处 一 一 让 开源 社区 












































http://git.or.cz/gitwiki/GitHosting 

















可 供 选 择 的 托管 服务 数量 繁多 ， 各 有 利 次 。 在 Git 官方 wiki | 
新 的 托管 服务 列表 





























由 于 本 

















4.9.1 


不 是 而 不 是 全 部 基于 项 目 。 意 谓 本 人 在 Github 上 托管 一 个 grit MH 
在 github.com/shacon/srit (译注 : 作者 在 GitHub 上 的 用 户 名 是 shacon) 。 不 存在 所 谓 某 个 项 
所 以 假如 第 一 作者 放弃 了 某 个 项 目 ， 它 可 以 无 颖 转移 到 其 它 用 户 的 旗下 。 
司 时 也 是 一 个 向 使 用 私有 仓库 的 用 户 收取 费用 的 商业 公司 ， 不 过 所 有 人 都 可 以 快捷 的 得 到 一 个 免费 
在 上 面 托管 任意 多 的 开源 项 目 。 我 们 将 快速 介绍 一 下 该 过 程 。 


而 是 
版 本 ， 

GitHub 
账户 并 


GitHub 和 大 多 数 的 代码 托管 站 点 在 处 理 项 目 命名 空间 的 方式 上 略 有 不 同 。GitHub 的 设计 更 侧 台 


无 法 全 部 一 一 介绍 它们 ， 而 本 人 CARTE: 指 本 











作者 Scott Chacon 

















更 方便 的 找到 该 项 





























上 的 Githosting 页 面 有 一 个 持续 更 


























托管 服务 





。 比 如 ， 


改 有 几 大 优 




















目 并 给 予 























刚好 在 其 中 之 一 工作 ， 我 们 





















































































































































GitHub 





























E 






















































































































































































GitHub 合 写 的 。 


托管 服务 的 大 致 印象 。 


是 少数 同时 提供 公共 托管 和 私人 托管 服务 的 站 点 之 


(译注 : 

















pap 





于 





的 话 ， 它 将 不 会 出 现在 github.c 











用 户 ， 而 


om/grit, 























的 官方 
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4.9.2 建立 账户 


P 




















第 一 个 必要 必要 步骤 是 注册 一 个 免费 的 账户 。 访 问 Pricing and Signup 
//github.com/plans 并 点 击 Free acount (免费 账户 ) 的 "Sign Up (注册 ) ” 











册页 面 






































o The first thing you need to do is set up 





a free user account. 




















(价格 与 注册 ) 页 面 http: 








按钮 ( 见 图 4.2) 
If you visit the 





， 进 入 


Pricing 
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and Signup page at http://github.com/plans and click the “Sign Up” 


button on the Free account 
(see figure 4-2), you' re taken to the signup page. 


COONS Dome Gude — Advanced 


Choose the plan that's right for you. 


Paid plans are biled monthly and can be upgradeddowngraded/terminated at any time without penalty. 


Open Source 


Free! eu 


E 4.2: GitHub 服务 简介 页 面 




















这 里 要 求 选择 一 个 系统 中 尚未 存在 的 用 户 名 ， 提 供 一 个 与 之 相连 的 电邮 地 址 ， 以 及 一 个 密码 ( 见 图 4.3) 。 








Confirm Password 





SSH Public Key (pisin ssh keys) 
Pase enter one key only You may acd move ater “his boki is not required © ugn ap 





Youle signing up for he free clan. If you Nave ay Questions 
please omal support, 


By signing up, you agree to the Torms of Service, Privacy, 
and Rolund polices. 


L 








图 4.3: The GitHub user signup form 
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4.9 节 Git 托管 服务 





























如 果 事 先 有 准备 ， 可 以 顺便 提供 SSH 公 钥 。 我 们 在 前 文中 的 “小 型 安装 ” 一 节 介 绍 过 生成 新 公 钥 的 方法 。 
把 生成 的 钥匙 对 中 的 公 钥 粘贴 到 SSH Public Key (SSH 公 钥 ) 文本 框 中 。 点 击 "explain ssh keys" fË 



































接 可 以 获取 在 所 有 主流 操作 系统 上 完成 该 步骤 的 介绍 。 点 击 "I agree, sign me up (同意 条 款 ， 让 我 注 















































A) ” 按钮 就 能 进入 新 用 户 的 控制 面板 〈 见 图 4.4) 。 


github 


Po 


News Feed © 


for you | from you 


一 ~ testinguser account | profe | log out 


( Search ) 
k 7 E30 dashboard | gists 


Dam A aos 


Your Repositories Icea a new one) 


all 1 pubic I private | sources I forks 


fit Welcome to GitHub! What's next? 


Create a Repository 
Find à Repository 


Peruse the GitHub Guides 


图 4.4: GitHub 用 户 面 板 








然后 就 可 以 建立 新 仓库 了 。 











4.9.3 建立 新 仓库 


点 击 用 户 面 板 上 仓库 旁边 的 “create a new one (新 建 ) ii 连接 。 进 入 Create a New Repository (新 








仓库 ) 表格 ( 见 图 4 


(e 





.5) e 


Create a New Repository 


Create a new empty repository into which you can push your local git repo. 
NOTE: If you intend to push a copy of a repository that is already hosted on GitHub, then you should fork & instead. 


Project Name 


iphone project 


Description 


iphone project for our mobile group 


Homepage URL 


Who has access to this reposaory? (vou can change ts late 
( Anyone (eor more about public repos) 
Vogade your plan to create more private repostones 


( Create Repository ) 


图 4.5: 在 GitHub 建立 新 仓库 





唯一 必 做 的 仅仅 是 提供 一 个 项 目 名 称 ， 当 然 也 可 以 添加 一 点 描述 。 搞 定 这 些 以 后 ,点 "Create Reposi- 





tory (建立 仓库 ) ” 











按钮 。 新 仓库 就 建立 起 来 了 ( 见 图 4-6) 。 
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* z 
A — de 
github ( ) toslingiesor account | profils | log aut 
‘POC ODMR — | Cuire Ades E30 diihneant gri 
lestinguser / iphone project (- ad) Ce usw) Ca) GA dh 
Desorption iphone project for pur mobio group pi 
Homecaga Chk bo cit qi 


Public Clone URL: gitdgitob.comAestingusaniphone: project oit E] 
Your Clone URL: gadshgithub. comdestingusen phone project gi E 


图 4.6: GitHub 项 目 头 信息 

















由 于 还 没有 提交 代码 ，GitHub 会 展示 如 何 创建 一 个 新 项 目 ， 如 何 推送 一 个 现存 项 目 ， 以 及 如 何 从 一 个 公 
FLAY Subversion 仓库 导入 项 目 GEE: 这 简直 是 公开 控 google code 和 sourceforge Wit) (A 
4.7) 。 























Global setup: 
Download and install Git 
git config --globol user.email test&github.com 


Next steps: 
mkdir iphone project 
cd iphone project 
git init 
touch README 
git add README 
git commit -m 'first commit' 
git remote add origin git&github.com:testinguser/iphone. project.git 
git push origin moster 


Existing Git Repo? 


cd existing git repo 
git remote add origin git&github.com:testinguser/iphone. project.git 
git push origin moster 


Importing a SVN Repo? 
Click here 


When you're done: 


Continue 


图 4.7: 新 仓库 指南 























该 指南 和 本 书 前 文中 的 介绍 类 似 。 要 把 一 个 非 Git 项 目 变 成 Git WA, iT 























$ git init 
$ git add . 


$ git commit -m 'initial commit' 

















且 拥 有 一 个 本 地 Git CE, $E GitHub 添加 为 远程 仓库 并 推送 master 分 支 : 
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$ git remote add origin git@github.com:testinguser/iphone_project.git 


$ git push origin master 





4.9% Git 托管 服务 





这 时 该 项 目 就 托管 在 GitHub 上 了 。 你 可 以 把 它 的 URL 发 给 每 个 希望 分 享 该 工程 的 人 。 本 例 的 URL 




















i= 




















4.8) 


testinguser / iphone project ( « edt ) ( * unwatch j 
Description: iphone project for our mobile group edit 
Homepage: Click to edit edit 

Public Clone URL: git:github.com/testinguser/iphone_project.git jE] 
Your Clone URL: — git@github.com:testinguseriphone_project.git [if] 


图 4.8: 项 目 开头 的 公共 URL 和 私有 URL © 


是 http://github.com/testinguser/iphone _ project。 你 将 在 项 目 页 面 的 头 部 发 现 有 两 个 Git URL ( 见 图 






































Public Clone URL (公共 克隆 URL) 是 一 个 公开 的 ， 只 读 的 Git URL， 任 何人 都 可 以 通过 它 克 隆 该 项 目 。 可 


























以 随意 的 散播 这 个 URL， 发 步 到 个 人 网 站 之 类 的 地 方 。 
Your Clone URL ( 私 用 克隆 URL) 是 一 个 给 予 SSH 的 读 写 URL， 只 有 使 用 与 上 传 的 SSH 













































































公 钥 对 应 的 密 钥 来 






































连接 时 ， 才 能 通过 它 进 行 读 写 操作 。 其 他 用 户 访问 项 目 页 面 的 时 候 看 不 到 该 URL 一 一 只 有 公 

















的 那个 




















4.9.4 从 Subversion 中 导入 项 目 























如 果 想 把 某 个 公共 Subversion 项 目 导 入 Git, GitHub 可 以 帮忙 。 在 指南 的 最 后 有 一 个 指 | 
























































可 导入 Subversion 
E 






























































页 面 的 链接 。 点 击 它 ， 可 以 得 到 一 个 表格 ， 它 包含 着 有 关 导 入 流程 的 信息 以 及 一 个 用 来 粘 册 
项 











公共 Subversion 








































































































目 连 接 的 文本 框 ( 见 图 4.9) 
pi 


杂工 程 的 方法 。 





4.9.5 开始 合作 





























1 果 项 目 很 大 ， 采 用 非 标准 结构 ， 或 者 是 私有 的 ， 那 么 该 流程 将 不 适用 。 在 第 七 章 ， 你 将 了 解 到 手动 导入 复 


现在 把 团队 里 其 他 的 人 也 加 进来 。 如 果 John, Josie 和 Jessica 都 在 GitHub 注册 了 账户 ， 要 给 他 们 向 仓 


























库 推 送 的 访问 权 ， 可 以 把 它们 加 为 项 目 合作 者 。 这 样 他 们 的 公 钥 就 能 用 来 向 仓库 推送 了 。 




































































点 击 项 目 页 面 上 方 的 "edit (编辑 ” 按钮 或 者 顶部 的 Admin (FH) 标签 进入 项 
4.10 





























管理 页 面 ( 见 图 





























为 了 给 另 一 个 用 户 添 加 项 目的 写 权 限 ， 点 击 “Add another collaborator (添加 男 一 个 合作 者 ) ” 链接 。 







































































一 个 新 文本 框 会 出 现 ， 用 来 输入 用 户 名 。 在 输入 用 户 名 的 同时 将 会 跳出 一 个 帮助 提示 ， 显 示 出 可 能 匹配 的 用 户 
名 。 找 到 正确 的 用 户 名 以 后 ， 点 Ada (添加 ) 按钮 ， 把 它 变 成 该 项 目的 合作 者 ( 见 图 4.11) e 
添加 完 合作 者 以 后 ， 就 可 以 在 Repository Collaborators (仓库 合作 者 ) 区 域 看 到 他 们 的 列表 QA 




















































































































4.12 
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以 通过 复制 现存 项 的 权限 设 定 来 得 到 相同 的 合作 者 群 组 。 





























如 果 需 要 取消 某 人 的 访问 权 ， 点 击 “revoke (撤销 ) ”， 他 的 推送 权限 就 被 删除 了 。 在 未 来 的 项 目 中 ， 可 
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Import a Subversion Repository 


* The import process could take as lite as 5 minutes to as long as 5 days depending on the size of your repository. This has 
everything to do with how slow subversion is, but we're working on speeding up the process. 


« E your subversion repository contains a non-standard directory structure. this import process will probably not work for you. Check 
Gut Qut Guide for running the impor yoursel. 


» This service currently only supports public subversion repositories. 
Project Name 

iphone project 

SVN Repository URL © 


| 





图 4.9: Subversion 导入 界面 


testinguser / iphone project GV (A) @ 
Description iphone project for our mobile group od* 

Homepage Click to edit oct 

Public Clone URL: git //github comtestinguser/phone. project ga ifj 


Your Clone URL: gitgithub.com31estieguserAphone. project git 加 
GitHub Page Generate Your Project Page 


Pull Requests: @) Add autoresponder 
RubyGem: (7) D 
Donations: @) Inactive odt 


Privacy Repository Collaborators 
人 This repo is viewable by everyone, Add another collaborator 
H you upgrade your pian you can make this repository privato! 


图 4.10: GitHub 管理 页 面 


Repository Collaborators 





图 4.11: 为 项 目 添 加 合作 者 


4.9.6 项 目 页 面 








在 推送 或 从 Subversion 导入 项 目 之 后 ， 你 会 得 到 一 个 类 似 图 4.13 的 项 目 主页 。 
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Repository Collaborators 


schacon revoke 


duncanparkes revoke 


spearce revoke 


it 
github Doosre  Qudes Agvarced 


maso! — albranches all tags 


(searen ) 


图 4.12: 项 目 合作 者 列表 


testinguser / iphone project (watch ) Ce domiad. 
Descripeon- iphone project for our mobile group 
Cione URL: git/igithub com^estnguserAphone project git E) 


initial commit 
^ schecon (author 
5 Gays ago 


iphone project / 


a Clesses/ 
Info.plist 
Moi rWindow. xib 

c4 build/ 

a iGit.xcodeproj/ 
iGitVienController.xib 
(Git Prefix.pch 


mgin.m 


其 他 人 访问 你 的 项 目 时 ， 他 们 会 看 到 该 页 面 。 它 包含 了 该 项 目 不 








5 days ogo 
5 days ago 
5 days ogo 
5 days ogo 
5 days ogo 
5 days ogo 
5 days ogo 
5 days ogo 


Home 


Comm 


tree 


itio 


itial 


itiol 


‘tial 


itial 


iticl 
itial 


itiol 


图 4.13: GitHub HA ER 


4.95] Git 托管 服务 





Pricing and Signup Repositories Blog Login 


3 ED @ 


it BceSccóóle?064c1741732c11502700c467574o 
CIOS S8813480f 6080711071514 05821a4 11642485 


history 
commit [schocon] 
commit [schacon] 
commit [schecon] 
commit [schecon] 
commit [schacon) 
commit [schocon] 
commit [schacon] 


commit [schocon] 











司 方 


逆序 的 commit 列表 ， 与 sit tos 命令 的 输出 类 似 。Network 标签 展示 
的 关系 图 。Downloads 标签 允许 你 上 传 项 目的 二 进 制 文件 ， 并 提供 了 指 
























































HA FREF o Wiki 标签 提供 了 一 个 用 来 撰写 文档 或 




















视 化 的 项 目 信息 与 数据 。 刚 开始 进入 的 Source 标签 页 面 列 出 了 项 目 


























文件 的 内 容 (如 果 该 文件 存在 的 





1) 











。 该 标签 还 包含 了 最 近 一 次 提交 























面 的 标签 。Commits 标签 将 按时 间 展 示 
所 有 fork 了 该 项 目 并 做 出 贡献 的 用 户 
向 该 项 目 所 有 标记 过 的 位 置 的 tar/zip 



















































































他 项 目 相关 信息 的 wiki e Graphs 标签 包含 了 一 些 可 
































的 主 目录 ; 并 且 在 下 方 自动 展示 README 









































的 相关 信息 。 


89 


第 4 章 服务 器 上 的 Git Scott Chacon Pro Git 


4.9.7 派生 (forking) 项 目 


的 项 目 ， 打 算 在 上 面 Hack 一 把 的 时 候 ， 可 以 点 击 页 面 上 方 的 “fork (派生 ) ” $E, GitHub 会 为 你 的 用 
户 复制 一 份 该 项 目 ， 这 样 你 就 可 以 向 它 推 送 内 容 了 。 





并 进行 推送 ， 而 后 项 目的 主要 维护 者 可 以 把 这 些 副本 添加 为 远程 仓库 ， 从 中 拉 取 更 新 的 内 容 进行 合 




















如 果 想 向 一 个 自己 没有 推送 权限 的 项 目 贡献 代码 ，GitHub 提倡 使 用 派生 (forking) 。 在 你 发 现 一 个 感 兴趣 







































































B 
TI 




































































使 用 这 个 办 法 ， 项 目 维护 者 不 用 操心 为 了 推送 权限 把 其 他 人 加 为 合作 者 的 麻烦 。 大 家 可 以 派生 一 个 项 目 副本 


















































































































































要 派生 一 个 项 目 ， 到 该 项 目的 页 面 (本 例 中 是 mojombo/chronic) 点 击 上 面 的 "fork" 按钮 ( 见 图 














4.14) 


4 





户 ， 添 加 一 个 新 的 项 目 并 开始 推送 。 如 果 你 的 项 目 是 开源 的 ， 它 还 同时 获得 了 对 庞大 的 开发 者 社区 的 可 视 性 ， 


2 h b —Ó—— - schacon account | profile | leg out 
(Search ) - 
github 一 r- CJ 182 


Browse O00s Advarced staftiools | dashboard | gists 


Source 
maser all branches al tacs 


mojombo / chro c CA) d watch ) ( € download. 11300 A) » 





Chr tural language date parsor 
hip Hchronic rubytorge.org 
RL: gitiigithub. commojombo/chronic git E) 


Added tests for RepecterMinute commit 18Be447630c 36d9ee4cóc 350/ 909001 151705673 
COEDS f cóc06706835796c002 ef 091 $794 285166 
Brian Browning (at parent GcÓod7104400c589«9788 3 cOGbece 59084 df 


图 4.14: 点 击 "fork" 按钮 来 获得 任意 项 目的 可 写 副 本 









































几 秒 钟 以 后 ， 你 将 进入 新 建 的 项 目 页 面 ， 显示 出 该 项 目 是 派生 自 另 一 个 项 目的 副本 CLA 4.15) 。 



























































schacon / chronic (< edit ) (= unwatch) 

Fark af majemboa/chronic 

Description: Chronic is a pure Ruby natural language date parser. edit 
Homepage: http-//chronic.rubyforge.org edit 

Public Clone URL: git://github.com/schacon/chronic.git lie] 

Your Clone URL:  git&github.com:schacon/chronic.git [i] 


图 4.15: 你 派生 的 项 目 副 本 


.9.8 GitHub 小 节 























GitHub 就 介绍 这 么 多 ， 不 过 意识 到 做 到 这 些 是 多 么 快捷 十 分 重要 。 不 过 几 分钟 的 时 间 ， 你 就 能 创建 一 个 账 






















































































td 


4 








上 区 成 员 可 能 会 派生 它 并 做 出 贡献 。 退 一 万 步 讲 ， 这 至 少 是 个 快速 开始 尝试 Git 的 好 办 法 。 

















.10 小节 














几 个 不 同 的 方案 可 以 让 你 获得 远程 Git 仓库 来 与 其 他 人 合作 或 分 享 你 的 成 果 。 





Au 














90 


Scott Chacon Pro Git 4.10 节 小 节 


























运行 自己 的 服务 器 意味 着 更 多 的 控制 权 以 及 在 防火 墙 内 部 操作 的 可 能 性 ， 然 而 这 样 的 服务 器 通常 需要 投入 
定 的 时 间 来 架设 和 维护 。 如 果 把 数据 放 在 托管 服务 上 ， 假 设 和 维护 变 得 十 分 简单 ， 然而， 你 不 得 不 把 代码 保存 
在 别人 的 服务 器 上 ， 很 多 公司 不 允许 这 种 做 法 。 
使 用 哪个 方案 或 哪 种 方案 的 组 合 对 你 和 你 的 团队 更 合适 ， 应 该 不 是 一 个 太 难 的 决定 。 

































































































































































分 布 式 Git 


























为 了 便于 项 
习 ， 我 们 已 经 学 
4 和 完成 分 布 式 了 


符 别 是 ， 

















A 
Ba 





J 














NS 





一 
ML 





的 所 有 


[ 作 流 程 。 
作为 项 目 页 献 者 时 ， 我 们 该 怎么 做 才能 方便 维护 者 采纳 更 


FA 
一 些 基 本 上 




















和 本 地 了 | 的 命令 。 接 下 来 ， 





[ 作 流 程 中 所 需 用 至 

















者 分 享 代码 ， 我 们 准备 好 了 一 台 服 务 器 存放 远程 Git 仓库 。 经 过 前 面 儿 章 的 学 

















我 们 要 学 习 下 如 何 利用 Git 来 组 




















新 ; 





























有 效 管理 大 量 











5.1 














同 传统 的 人 
活 多 样 。 在 集 


不 








' 式 版 本 控制 系统 (CVCS) 不 同 ， 开 发 者 之 间 
中 式 系统 


时 贡献 者 的 提交 。 


分 布 式 工作 流程 





的 协作 方式 
， 每 个 开发 者 就 像 是 连接 在 集线器 上 的 节点 ， 
































网 络 中 ， 每 个 


发 者 同时 扮演 


因 着 Git 的 分 布 式 
彼此 的 了 


或 者 作为 项 目 维护 者 时 ， 又 该 怎样 




















特性 而 变 得 更 为 灵 
Git 


[ 作 方 式 大 体 相 像 。 而 在 





























着 节点 和 集线器 的 角色 ， 这 就 是 说 ， 每 一 个 开 























发 者 都 可 以 将 自己 的 代码 贡献 到 另 

















外 一 个 开发 者 的 仓库 
码 。 于 是 ，Git 的 分 布 式 协 人 











论 各 





式 ， 并 分 别 讨论 各 自 





5.1.1 

















AI 
































] 











建立 自己 的 公共 仓库 ， 让 其 他 开发 者 基于 自 
便 可 以 衍生 出 种 种 不 同 的 工作 流程 ， 我 会 在 接 


， 或 者 

































































的 工作 开始 ， 为 自己 的 仓库 贡献 代 
下 来 的 章节 介绍 几 种 常见 的 应 用 方 



































M, 























H 
Ù 





ii 
的 优 缺点 。 你 可 以 选择 其 中 的 一 种 ， 或 者 结合 





v. 























用 到 你 自己 的 项 目 中 。 














集中 式 工作 流 
[ 作 流 程 使 

















的 都 是 单 点 协作 模型 。 一 个 存放 代码 仓库 的 




















N 








交 的 代码 。 所 有 的 姑 
WA 5.1) ° 














PAC aie BA Tk, PEA UD SRA aRTR RA, 7 












图 


集中 式 工作 流 





5.1: 

















时 的 工作 就 是 和 


developer 





心服 务 器 ， 可 以 接受 所 有 开发 者 提 
FP 心 仓库 同步 数据 











eb 








如 果 两 个 开发 者 从 
送 到 共享 服务 器 。 第 二 个 开发 者 在 提交 他 的 修订 之 前 ， 必 须 》 

















心 仓库 克隆 代码 下 来 ， 同 时 作 了 一 些 修订 ， 那 么 只 有 
EC 下 载 合并 服务 


口 












































第 一 个 开发 者 可 以 顺利 地 把 数据 推 
器 上 的 数据 ， 解 决 冲突 之 后 才能 推 
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Rot 分 布 式 Git 
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送 数据 到 共享 服务 器 上 。 在 Git 中 这 么 用 也 决 无 问题 ， 这 就 好 比 是 在 用 Subversion (或 其 他 CVCS) 一 样 ， 
可 以 很 好 地 工作 

如 果 你 的 团队 不 是 很 大 ， 或 者 大 家 都 已 经 习惯 了 使 用 集中 式 工 作 流 程 ， 完 全 可 以 采用 这 种 简单 的 模式 。 只 需 
要 配置 好 一 台中 心服 务 器 ， 并 给 每 个 人 推送 数据 的 权限 ， 就 可 以 开展 工作 了 。 但 如 果 提 交代 码 时 有 冲突 ， Git 
根本 就 不 会 让 用 户 履 盖 他 人 代码 ， 它 直接 驶 回 第 二 个 人 的 提交 操作 。 这 就 等 于 告诉 提交 者 ， 你 所 作 的 修订 无 法 
通过 快 近 (fast-forward) 来 合并 ， 你 必须 先 拉 取 最 新 数据 下 来 ， 手 工 解决 冲突 合并 后 ， 才 能 继续 推送 新 的 提 
交 。 绝 大 多 数 人 都 熟悉 和 了 解 这 种 模式 的 工作 方式 ， 所 以 使 用 也 非常 广泛 。 
5.1.2 集成 管理 员工 作 流 

由 于 Git 人 允许 使 用 多 个 远程 仓库 ， 开 发 者 便 可 以 建立 自己 的 公共 仓库 ， 往 里 面 写 数据 并 共享 给 他 人 ， 而 同 
时 又 可 以 从 别人 的 仓库 中 提取 他 们 的 更 新 过 来 。 这 种 情形 通常 都 会 有 个 代表 着 官方 发 布 的 项 目 仓库 (blessed 
repository) ， 开 发 者 们 由 此 仓库 克隆 出 一 个 自己 的 公共 仓库 (developer public) ， 然 后 将 自己 的 提交 推 
送 上 去 ， 请 求 官方 仓库 的 维护 者 拉 取 更 新 合并 到 主 项 目 。 维 护 者 在 自己 的 本 地 也 有 个 克隆 仓库 (integration 
manager) ， 他 可 以 将 你 的 公共 仓库 作为 远程 仓库 添加 进来 ， 经 过 测试 无 误 后 合并 到 主干 分 支 ， 然 后 再 推送 到 
官方 仓库 。 工 作 流程 看 起 来 就 像 图 5.2 PR: 

1. 项 目 维护 者 可 以 推送 数据 到 公共 仓库 blessed repository ° 

2. 贡献 者 克隆 此 人 仓库， 修订 或 编写 新 代码 。 

3. 贡献 者 推送 数据 到 自己 的 公共 仓库 developer public。 

4. 贡献 者 给 维护 者 发 送 邮件 ， 请 求 拉 取 自己 的 最 新 修订 。 

5. 维护 者 在 自己 本 地 的 integration manger 仓库 中 ， 将 贡献 者 的 仓库 加 为 远程 仓库 ， 合 并 更 新 并 做 测 

试 。 
6. 维护 者 将 合并 后 的 更 新 推送 到 主 仓库 blessed repository ° 
l1 
public public 
E 5.2: 集成 管理 员工 作 流 

在 GitHub 网 站 上 使 用 得 最 多 的 就 是 这 种 工作 流 。 人 们 可 以 复制 (fork 亦 即 克 隆 ) 某 个 项 目 到 自己 的 列表 

1， 成 为 自己 的 公共 仓库 。 随 后 将 自己 的 更 新 提交 到 这 个 仓库 ， 所 有 人 都 可 以 看 到 你 的 每 次 更 新 。 这 么 做 最 主 
要 的 优点 在 于 ， 你 可 以 按照 自己 的 节奏 继续 工作 ， 而 不 必 等 待 维护 者 处 理 你 提交 的 更 新 ， 而 维护 者 也 可 以 按照 

1 的 节奏 ， 任 何 时 候 都 可 以 过 来 处 理 接 纳 你 的 贡献 。 

5.1.3 司令 官 与 副官 工作 流 

这 其 实 是 上 一 种 工作 流 的 变 体 。 一 般 超大 型 的 项 目 才 会 用 到 这 样 的 工作 方式 ， 像 是 拥有 数 百 协 作 开 发 者 的 
Linux 内 核 项 目 就 是 如 此 。 各 个 集成 管理 员 分 别 负 责 集成 项 目 中 的 特定 部 分 ， 所 以 称 为 副官 (lieutenant) 。 
而 所 有 这 些 集 成 管理 员 头 上 还 有 一 位 负责 统筹 的 总 集成 管理 员 ， 称 为 司令 官 (dictator) 。 司 令 官 维护 的 仓库 

于 提供 所 有 协作 者 拉 取 最 新 集成 的 项 目 代 码 。 整 个 流程 看 起 来 如 图 5.3 所 示 : 
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Scott Chacon Pro Git 5.29 为 项 目 作 贡 献 












































1. 一 般 的 开发 者 在 自己 的 特性 分 支 上 工作 ， 并 不 定期 地 根据 主干 分 支 (dectator 上 的 master) WE ° 
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2. 副官 (lieutenant) 将 普通 开发 者 的 特性 分 支 合并 到 自己 的 master 分 支 






























































ulj 


JSE (dictator) 将 所 有 副官 的 master 分 支 并 入 自己 的 master x ° 
























































4. HIS’ (dictator) 将 集成 后 的 master 分 文 推送 到 共享 仓库 blessed repository 中 ， 以 便 所 有 其 他 
开发 者 以 此 为 基础 进行 衍 合 。 


















































developer developer 
public public 


图 5.3: 司令 官 与 副官 工作 流 


























这 种 工作 流程 并 不 常用 ， 只 有 当 项 目 极 为 庞杂 ， 或 者 需要 多 级 别管 理 时 ， 才 会 体现 出 优势 。 利 用 这 种 方式 ， 
项 目 总 负责 人 ( 即 司令 官 ) 可 以 把 大 量 分 散 的 集成 工作 委托 给 不 同 的 小 组 负责 人 分 别处 理 ， 最 后 再 统筹 起 来 ， 
如 此 各 人 的 职责 清晰 明确 ， 也 不 易 出 错 〈 译 注 ; 此 乃 分 而 治之 ) 。 
以 上 介绍 的 是 常见 的 分 布 式 系 统 可 以 应 用 的 工作 流程 ， 当 然 不 止 于 Git 。 在 实际 的 开发 工作 中 ， 你 可 能 会 遇 
到 各 种 为 了 满足 特定 需求 而 有 所 变化 的 工作 方式 。 我 想 现在 你 应 该 已 经 清楚 ， 接 下 来 自己 需要 用 哪 种 方式 开展 
工作 了 。 下 市 我 还 会 再 举 些 例子 ， 看 看 各 式 工 作 流 中 的 每 个 角色 具体 应 该 如 何 操作 。 
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5.2 为 项 目 作 贡献 





接 下 来 ， 我 们 来 学 习 一 下 作为 项 目 贡 献 者 ， 会 有 哪些 常见 的 工作 模式 。 

不 过 要 说 清楚 整个 协作 过 程 真 的 很 难 ，Git 如 此 灵活 ， 人 们 的 协作 方式 便 可 以 各 式 各 样 ， 没 有 国定 不 变 的 范 
式 可 循 ， 而 每 个 项 目的 具体 情况 又 多 少 会 有 些 不 同 ， 比 如 说 参与 者 的 规模 ， 所 选择 的 工作 流程 ， 每 个 人 的 提交 
权限 ， 以 及 Git 以 外 贡献 等 等 ， 都 会 影响 到 具体 操作 的 细节 。 
当 其 冲 的 是 参与 者 规模 。 项 目 中 有 多 少 开 发 者 是 经 常 提交 代码 的 ? 经 常 又 是 多 久 呢 ? 大 多 数 两 至 三 人 的 小 
团队 ， 一 天 大 约 只 有 几 次 提交 ， 如 果 不 是 什么 热门 项 目的 话 就 更 少 了 。 可 要 是 在 大 公司 里 ， 或 者 大 项 目 中 ， 参 
与 者 可 以 多 到 上 千 ， 每 天 都 会 有 十 几 个 上 百 个 补丁 提交 上 来 。 这 种 差异 带 来 的 影响 是 显著 的 ， 越 是 多 的 人 参与 
进来 ， 就 越 难保 证 每 次 合并 正确 无 误 。 你 正在 工作 的 代码 ， 可 能 会 因为 合并 进来 其 他 人 的 更 新 而 变 得 过 时 ， 直 
至 受 创 无 法 运行 。 而 已 经 提交 上 去 的 更 新 ， 也 可 能 在 等 着 审核 合并 的 过 程 中 变 得 过 时 。 那 么 ， 我 们 该 怎样 做 才 
能 确保 代码 是 最 新 的 ， 提 交 的 补丁 也 是 可 用 的 呢 ? 
接 下 来 便 是 项 目 所 采用 的 工作 流 。 是 集中 式 的 ， 每 个 开发 者 都 具有 等 同 的 写 权 限 ? 项 目 是 否 有 专人 负责 检查 
所 有 补丁 ? 是 不 是 所 有 补丁 都 做 过 同行 复 阅 (peer-review) 再 通过 审核 的 ? 你 是 否 参与 审核 过 程 ? 如 果 使 用 
副官 系统 ， 那 你 是 不 是 限定 于 只 能 向 此 副官 提交 ? 
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还 有 你 的 提交 权限 。 有 或 没有 向 主 项 目 提交 更 新 的 权限 ， 结 果 完 全 不 同 ， 











7 






























































如 果 不 能 直接 提交 更 新 ， 那 该 如 何 贡献 自己 的 














提交 频率 呢 ? 
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所 有 以 上 这 些 问 题 都 会 或 多 或 少 影响 到 最 终 采 





























VRBE? 是 不 是 该 有 个 什么 策略 








3 的 工作 流 。 接 下 来 ， 我 会 在 









































? 你 每 次 贡献 代码 会 


接 决 定 最 终 采 用 怎样 的 工作 流 。 





多 少量 ? 






































一 系列 由 简 入 繁 的 具体 用 例 
























































逐一 阐述 。 此 后 在 实践 时 ， 应 该 可 以 借鉴 这 里 的 例子 ， 略 作 调 整 ， 以 满足 实际 需要 构建 自己 的 工作 流 。 














5.2.1 提交 指南 























开始 分 析 特 定 用 例 之 前 ， 先 来 了 解 
































配合 。Git 项 目 本 身 就 提供 ] 
提示 ， 从 如 何 编 






























































份 文档 (Git 项 


























撰 提交 说 明 到 提交 补丁 ， 不 一 























首先 ， 请 不 要 在 更 新 中 提交 























运行 git diff --check， 会 把 可 能 的 多 余 














J] x 替换 掉 : 














$ git diff --check 








mi 





源 代码 


I] AE ° 


余 的 字符 (whitespace 














lib/simplegit.rb:5: trailing whitespace. 


* Ggit dir = File.expand path(git dir)XX 


lib/simplegit.rb:7: trailing whitespace. 


* XXXXXXXXXXX 


lib/simplegit.rb:26: trailing whitespace. 


* def command(git cmd)XXXX 














这 样 在 提交 之 前 你 就 可 以 看 到 这 类 问题 ， 及 时 解决 以 免 




















接 下 来 ， 请 将 每 次 提交 限定 二 完成 一 次 逻辑 功能 。 





白字 符 修 ] 





E 列 出 来 





















































如 何 撰写 提交 说 明 。 一 份 好 的 提交 指南 可 以 帮助 协作 者 更 轻松 更 有 效 地 





H 中 Documentation/SubmittingPatches) K 列 数 了 大 量 








o Git AF 


检查 此 


























。 下面 的 示例 ， 























RE 





类 问题 的 方法 ， 在 提交 之 前 ， 先 











ES, 
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ZS FEA tig TH iz AZ 

















RTL 














o 





人 LL. 





4 
[z 























提交 都 更 易于 理解 。 请 不 要 在 周末 穷 追 猛 打 一 次 性 解 
可 能 利用 暂 存 区 域 ， 将 之 前 的 改动 分 
动 的 是 同一 个 文件 ， 可 以 试 试看 sit add patch 












































杂 在 一 起 的 大 ] 


绍 ) 。 无 论 是 五 次 小 提交 还 是 混 























解 为 每 次 修复 一 个 
的 方式 ; 





















































后 ， 更 便于 其 他 开发 者 复 阅 。 这 么 做 也 方便 自 





















































提交 历史 ， 同 暂 存 区 域 交互 的 技巧 和 工具 ， 以 
最 后 需要 谨 记 的 是 提交 说 明 的 撰写 。 写 得 好 可 
行 以 内 ，50 个 字符 以 下 ， 简 明 扼要 地 描述 更 新 内 





























可 能 的 话 ， 适 


ni 
= 








当地 分 





























五 个 问题 ， 而 最 后 拖 到 























SaaS AA A 

















"2 























提交 ， 最 终 分 文 末端 的 项 
将 来 取消 定 























快照 


AM 








HEKER GATA ETRZNS 


立 该 还 是 一 样 的， 但 分 解 开 来 之 





色 的 日 字符 




















解 为 多 次 小 更 新 ， 以 























更 每 次 小 型 








AP BH 



































周一 再 提交 。 就 算是 ; 





文 样 也 请 尽 

















问题 ， 再 分 别提 交 和 加 注 说 明 。 如 果 针 对 





个 问题 改 





> 


























问题 的 修复 








再 详细 介 


























。 我们 将 在 第 六 章 介 绍 一 些 重 写 










































































协作 起 来 更 轻 


mi 


个 干净 有 意义 ， 











易于 理解 的 提交 历史 








o 











般 来 说 ， 提 交 说 明 最 好 限制 在 一 




































































容 ， 空 


fim. H 




































































说 明 应 该 用 禄 使 现在 式 语 态 ， 上 











者 撰写 详尽 注解 ， 包 括 本 次 修 

















的 因由 ， 以 及 
上 如， 不 要 说 成 


























"Add tests for”。 下 面 是 来 




















本 次 更 新 的 简要 描述 (50 个 字符 以 内 ) 





BI Jer 7S 











‘6 





同 实现 之 间 的 比较 





I added 





tpope.net 的 7 


如 果 必 要 ， 此 处 展开 详尽 阅 述 。 段 落 宽 度 限定 在 72 个 字符 以 内 。 
某 些 情况 下 ， 第 一 行 的 简要 描述 将 用 作 邮 件 标题 ， 其 余部 分 作为 邮件 正文 。 
其 间 的 空 行 是 必要 的 ， 以 区 分 两 者 (当然 没有 正文 另 当 别 论 ) 。 
如 果 并 在 一 起 ，rebase 这 样 的 工具 就 可 能 会 迷惑 。 


另 起 空 行 后 ， 再 进一步 补充 其 他 说 明 。 


- 可 以 使 用 这 样 的 条 目 列举 式 。 
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tests for 











zh 














开 详 细 注解 。Git 项 目 本 身 需 要 开发 





























“Adding tests for” 








[im Pope 原创 的 提交 





说 明 格 式 模版 ， 供 参考 : 


也 该 借鉴 这 种 做 法 。 另 外 ， 提 区 

















而 应 该 用 








































































































































































































































































































































































































































































































































































































































































































































































































































































































Scott Chacon Pro Git 5.29 为 项 目 作 贡 献 
- 一 般 以 单个 空格 紧 跟 短 划 线 或 者 星 号 作为 每 项 条 目的 起 始 符 。 每 个 条 目 间 用 一 空 行 隔 开 。 

不 过 这 里 按 自己 项 目的 约定 ， 可 以 略 作 变化 。 

如 果 你 的 提交 说 明 都 用 这 样 的 格式 来 书写 ， 好 多 事情 就 可 以 变 得 十 分 简单 。Git 项 目 本 身 就 是 这 样 要 求 的 ， 
我 强烈 建议 你 到 Git 项 目 仓库 下 运行 sit tos —no-nerses 看 看 ， 所 有 提交 历史 的 说 明 是 怎样 撰写 的 。 (译注 : 
如 果 现 年 还 没 有 克隆 git 项 E 源 代码 ， 是 时 候 git clone git://git.kernel.org/pub/scm/git/git.git J ° ) 

为 简单 起 见 ， 在 接 下 来 的 例子 (及 本 书 随后 的 所 有 演示 ) 中 ， 我 都 不 会 用 这 种 格式 ， 而 使 用 -m 选项 提交 
git commit。 不 过 请 还 是 按照 我 之 前 讲 的 做 ， 别 学 我 这 里 偷懒 的 方式 。 

5.2.2. 私有 的 小 型 团队 

我 们 从 最 简单 的 情况 开始 ， 一 个 私有 项 目 ， 与 你 起 协作 的 还 有 另外 一 到 两 位 开发 者 。 这 里 说 私有 ， 是 指 源 
代码 不 公 他 人 无 法 访问 项 目 仓库 。 而 你 和 其 他 开发 者 则 都 具有 推送 数据 到 仓库 的 权限 。 

这 种 情况 下 ， 你 们 可 以 用 Subversion 或 其 他 集中 式 版 本 控制 系统 类 似 的 工作 流 来 协作 。 你 仍然 可 以 得 到 
Git 带 来 的 其 他 好 人 处， 离线 提交 ， 快 速 分 支 与 合并 等 等 ， 但 工作 流程 还 是 差不多 的 。 主 要 区 别 在 于 ， 合 并 操作 
发 生 在 客户 端 而 非 服务 器 上 。 让 我 们 来 看 看 ， 两 个 开发 者 一 起 使 用 同一 个 共享 仓库 ， 会 发 生 些 什么 。 第 一 个 
A, John, WET OE, TEE, EAE. (下 面 的 例子 中 省 略 了 常规 提示 ， 用 代替 以 节约 版 
Hio j 

















# John's Machine 
$ git clone john@githost:simplegit.git 
Initialized empty Git repository in /home/john/simplegit/.git/ 


$ cd simplegit/ 

$ vim lib/simplegit.rb 

$ git commit -am 'removed invalid default value' 
[master 738ee87] removed invalid default value 


1 files changed, 1 insertions(+), 1 deletions(-) 





LL. 





第 二 个 


















































# Jessica's Machine 
$ git clone jessica@githost:simplegit.git 
Initialized empty Git repository in /home/jessica/simplegit/.git/ 


$ cd simplegit/ 

$ vim TODO 

$ git commit -am 'add reset task' 
[master fbff5bc]| add reset task 


1 files changed, 1 insertions(+), 0 deletions(-) 





HE, Jessica 将 她 的 工作 推送 到 服务 器 上 : 





# Jessica's Machine 


，yessica， 一 样 这 么 做 : 克隆 仓库 ， 提 交 更 新 : 
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$ git push origin master 


To jessicaegithost:simplegit.git 
ledee6b..fbff5bc master -> master 

















John PAWE BCA TE EX: 














# John's Machine 
$ git push origin master 
To john@githost:simplegit.git 
! [rejected] master -> master (non-fast forward) 


error: failed to push some refs to 'john@githost:simplegit.git' 











John 的 推送 操作 被 驳回 ， 因 为 Jessica 已 经 推送 了 新 的 数据 上 去 。 请 注意 ， 特 别 是 你 用 惯 了 Subversion 
的 话 ， 这 里 其 实 修改 的 是 两 个 文件 ， 而 不 是 同一 个 文件 的 同一 个 地 方 。Subversion 会 在 服务 器 端 自动 合并 提 
交 上 来 的 更 新 ， 而 Git 则 必须 先 在 本 地 合并 后 才能 推送 。 于 是 ，John 不 得 不 先 把 Jessica 的 更 新 拉 下 来 : 


























H 















































| 






























































$ git fetch origin 


From john@githost:simplegit 
+ 049d078...fbffb5bc master -» origin/master 


HEA), John 的 本 地 仓库 如 图 5.4 所 示 : 








E 





ergimmaser | 


图 5.4: John 的 仓库 历史 


































































































虽然 John PET Jessica 推送 到 服务 器 的 最 近 更 新 (fbff5) ， 但 目前 只 是 origin/master 指针 指向 它 ， 
而 当前 的 本 地 分 支 master 仍然 指向 自己 的 更 新 (738ee) ， 所 以 需要 先 把 她 的 提交 合并 过 来 ， 才 能 继续 推送 数 
据 : 














5.29 为 项 目 作 贡献 
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$ git merge origin/master 
Merge made by recursive. 


TODO | il s 
1 files changed, 1 insertions(+), 0 deletions(-) 





图 5.5 所 示 : 


<--- 4b078 72bbc 














还 好 ， 合 并 过 程 非常 顺利 ， 没 有 冲突 ， 现 在 John 的 提交 历史 如 


























wormaner | 


图 5.5: 合并 origin/master 后 John 的 仓库 历史 








LE, RASH (72bbc) 推送 到 服务 器 上 : 

















T 
di 

















HUE, John 应 该 再 测试 一 下 代码 是 否 仍然 1 





$ git push origin master 


To john@githost:simplegit.git 
fbff5bc..72bbc59 master -> master 





BEX, John 的 提交 历史 变 为 图 5.6 Brom: 





origin/master 


图 5.6: 推送 后 John 的 仓库 历史 

















FE 分 支 工 作 了 。 她 创建 了 issue54 并 提交 了 三 次 更 新 。 她 还 没 














而 在 这 段 时 间 ，Jessica 已 经 开始 在 另 一 个 特 怕 
有 下 载 John 提交 的 合并 结果 ， 所 以 提交 历史 如 图 5.7 Arm: 
Jessica 想 要 先 和 服务 器 上 的 数据 同步 ， 所 以 先 下 载 数据 : 























# Jessica's Machine 
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Bl dada naa 


图 5.7: Jessica 的 提交 历史 


$ git fetch origin 


From jessica@githost:simplegit 


fbff5bc..72bbc59 master -> origin/master 














于 是 Jessica 的 本 地 仓库 历史 多 出 了 John 的 两 次 提交 (738ee 和 72bbc) ， 如 图 5.8 所 示 : 


E Š 


(73800 | 


enya | in/master 


图 5.8: 获取 John 的 更 新 之 后 Jessica 的 提交 历史 





















































^, adr 是 运行 git log 查 


IERT, Jessica 在 特性 分 支 上 的 工作 已 经 完成 ， 但 她 想 在 推送 数据 之 前 ， 先 确认 下 要 并 进来 的 数据 究 况 是 什 























$ git log --no-merges origin/master ^issue54 
commit 738ee872852dfaa9d6634e0dea7a324040193016 
Author: John Smith <jsmith@example.com> 

Date: Fri May 29 16:01:27 2009 -0700 


removed invalid default value 









































MÆ, Jessica 可 以 将 特性 分 支 上 的 工作 并 到 master 分 文 ， 然 后 再 并 入 John 的 工作 (origin/master) 到 
己 的 master 分 文 ， 最 后 再 推送 回 服务 器 。 当 然 ， 得 先 切 回 主 分 支 才能 集成 所 有 数据 : 



















































































$ git checkout master 
Switched to branch "master" 


Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. 








要 合并 origin/master 或 issues 分 支 ， 谁 先 谁 后 都 没有 关系 ， 因 为 它们 都 在 上 游 (upstream) (HELE: 想像 
分 又 的 更 新 像 是 汇流 成 河 的 源头 ， 所 以 上 游 upstream 是 指 最 新 的 提交 ) ， 所 以 无 所 谓 先 后 顺序 ， 最 终 合并 后 
的 内 容 快照 都 是 一 样 的 ， 而 仅 是 提交 历史 看 起 来 会 有 些 先 后 差别 。Jessica 选择 先 合并 issue54; 
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$ git merge issue54 
Updating fbffb5bc..4af4298 
Fast forward 
README | dox 
lib/simplegit.rb | (S) kitit- 
2 files changed, 6 insertions(+), 1 deletions(-) 











正如 所 见 ， 没 有 神 突 发 生 ， 仅 是 一 次 简单 快 进 。 现 在 Jessica 











= 


$ git merge origin/master 
Auto-merging lib/simplegit.rb 
Merge made by recursive. 
lib/simplegit.rb | DE 
1 files changed, 1 insertions(+), 1 deletions(-) 
































rH 



































It John 的 工作 (origin/master) 




















所 有 的 合并 都 非常 干净 。 现 在 Jessica 的 提交 历史 如 图 5.9 所 示 : 





m) e m 9) 9) e] 


图 5.9: 合并 John 的 更 新 后 Jessica 的 提交 历史 











现在 Jessica 已 经 可 以 在 自己 






































,的 master 分 文中 访问 orisin/master 的 最 新 改动 ， 所 以 她 应 该 可 以 成 功 推送 


最 后 的 合并 结果 到 服务 器 上 (假设 John 此 时 没 再 推送 新 数据 上 来 ) : 





$ git push origin master 


To jessica@githost:simplegit.git 
72bbc59. .8059c15 master -> master 
































成 功 合并 了 对 方 的 工作 成 果 ， 最 新 的 提交 历史 如 图 5.10 所 示 : 

















发 者 都 提交 了 和 若 














u 





"Uu Ce) 





i): 





图 5.10: Jessica 推送 数据 后 的 提交 历史 
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以 上 就 是 最 简单 的 协作 方式 之 一 : 先 在 自己 的 特性 分 文中 工作 一 段 时 间 ， 完 成 后 合并 到 自己 的 master 分 
L: AE PRAH origin/master 上 的 更 新 〈 如 果 有 的 话 ) ， 再 推 回 远 程 服务 器 。 一 般 的 协作 流程 如 图 5.11 所 

































































Jessica 






k 


k 


Jessica 


图 5.11: 多 用 户 共享 仓 库 协 作 方 式 的 一 般 工 作 流程 时 序 


5.2.3 私有 团队 间 协 作 


现在 我 们 来 看 更 大 一 点 规模 的 私有 团队 协作 。 如 果 有 几 个 小 组 分 头 负责 若干 特性 的 开发 和 集成 ， 那 他 们 之 间 
的 协作 过 程 是 怎样 的 。 

假设 John 和 Jessica 一 起 负责 开发 某 项 特性 A， 而 同时 Jessica 和 Josie 一 起 负责 开发 男 一 项 功能 B。 
公司 使 用 典型 的 集成 管理 员 式 工 作 流 ， 每 个 组 都 有 一 名 管理 员 负 责 集 成 本 组 代码 ， 及 更 新 项 目 主 仓库 的 master 
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4x ° BUR 




















开发 都 在 代表 小 组 的 分 文 


上 进 和 








让 我 们 跟随 Jessica 的 视角 
作 。 克 隆 生成 本 地 仓库 后 ， 她 打算 先 着 3 




















看 看 她 的 了 


































































































# Jessica's Machine 


$ git checkout -b featureA 


Switched to a new branch "featureA" 


$ vim lib/simplegit.rb 


$ git commit -am 'add limit to log function' 


[featureA 3300904] add limit to log function 


1 files changed, 1 insertions(+), 1 deletions(-) 

















此 刻 ， 她 需要 分 享 
限 推 送 数 据 到 主 仓库 
作 : 



































$ git push origin featureA 


前 的 进 

































































展 给 John， 于 是 她 将 
的 master 分 支 (只 有 集成 管 ERA 





To jessica@githost:simplegit.git 


* [new branch] 


Jessica 发 邮件 给 John 让 他 上 来 看 看 featureA 分 支 上 的 i 
作 ， 和 Josie 一 起 开发 featureB 上 的 








# Jessica's Machine 


$ git fetch origin 


featureA -> featureA 




















特性 





$ git checkout -b featureB origin/master 


Switched to a new branch "featureB" 











随后 ， 








$ vim lib/simplegit.rb 


Jessica 在 featureB 上 提交 了 A 




















此 权限 ) ， 所 以 








f= Ate 4 








项 特性 ， 同 时 和 不 同 
了 新 的 featureA S, 4 


,的 featureA 分 支 提交 到 服务 器 。 
只 能 将 此 分 支 失 














P 


o 





EN 


SE 











Bo MR 


TN > 



































i 
Su 


$ git commit -am 'made the ls-tree function recursive' 


[featureB e5b0fdc] made the 1s-tree function recursive 


1 files changed, 1 insertions(+), 1 deletions(-) 


$ vim lib/simplegit.rb 


$ git commit -am ‘add 1s-files' 
[featureB 8512791] add 1s-files 


1 files changed, 5 insertions(*), 0 deletions(-) 























ee 


现在 Jessica f 


新 历史 如 图 


























FE 准备 推送 











Jessica |] 








,的 进 











T 





featureBee xr * 这 样 ， 


器 。 她 用 eit fetch 下 载 Josie 的 最 新 代码 ; 





Jessica 就 必须 多 








5.12 所 示 : 
E FX, AES Josie 的 来 信 ， 说 是 她 


N: 


DR Josie HJARA 


H 


先 创 建 上 





J 





A 








5.29 为 项 


小 组 的 




















T 









































































































































RE: 











VETERA 


起 协 











他 的 反馈 之 前 ，Jessica 决定 继续 工 
Lay x, 分 又 点 以 服务 器 上 的 master 7 




















经 将 自己 的 工作 推 到 月 
到 自己 本 地 分 文 二 能 再 一 起 失 























于 Jessica 没有 权 
去 同 John 共享 协 
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e5b0f 85127 


Ea 


图 5.12: Jessica 的 更 新 历史 


gu 


$ git fetch origin 


From jessica@githost:simplegit 


* [new branch] featureBee -> origin/featureBee 
































Lu 
$ 
K 


























然后 Jessica 使 j git merge 将 此 分 支 合并 到 自 


TN 


$ git merge origin/featureBee 
Auto-merging lib/simplegit.rb 


Merge made by recursive. 


lib/simplegit.rb | A +t 


l files changed, 4 insertions(+), 0 deletions(-) 





合并 很 顺利 ， 但 另外 有 个 小 问题 : 她 要 推送 自己 的 features 分 文 到 服务 器 上 的 featureBee 分 文 上 去 。 当 然 ， 


这 


她 可 以 使 用 冒号 C) 格式 指定 目标 分 支 : 

























































































$ git push origin featureB:featureBee 


To jessica@githost:simplegit.git 
fba9af8..cd685dl featureB -> featureBee 















































我 们 称 此 为 refspec。 更 多 有 关于 Git refspec 的 讨论 和 使 用 方式 会 在 第 九 章 作 详 细 立 述 。 
接 下 来 ，John 发 邮件 给 Jessica 告诉 她 ， 他 看 了 之 后 作 了 些 修 改 ， 已 经 推 回 服务 器 featureA 分 文 ， 请 她 过 
下 。 于 是 Jessica 运行 git fetch 下 载 最 新 数据 : 
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$ git fetch origin 


From jessica@githost:simplegit 


3300904..aad881d  featureA -» origin/featureA 
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目 作 贡献 











接 下 来 便 可 以 用 eit log 查看 更 新 了 些 什么 : 





$ git log origin/featureA ^featureA 

commit aad881dl54acdaeb2b6b18ea0e827ed8a6d671e6 
Author: John Smith <jsmith@example.com> 

Date: Fri May 29 19:57:33 2009 -0700 


changed log output to 30 from 25 
































最 后 ， 她 将 John 的 工作 合并 到 自己 的 feature 分 支 
































$ git checkout featureA 
Switched to branch "featureA" 
$ git merge origin/featureA 
Updating 3300904..aad881d 
Fast forward 
lib/simplegit.rb | 10 + 二 + 十 十 十 十 十 十 一 


1 files changed, 9 insertions(*), 1 deletions(-) 





Jessica 稍 做 一 番 修 整 后 同步 到 服务 器 : 














$ git commit -am 'small tweak' 
[featureA ed774b3] small tweak 
1 files changed, 1 insertions(+), 1 deletions(-) 


$ git push origin featureA 


To jessica@githost:simplegit.git 
3300904..ed774b3 featureA -> featureA 





现在 的 Jessica 提交 历史 如 图 5.13 Bro: 





origin/featureA 


Dor 
e5b0f 85127 cd685 


图 5.103: 在 特性 分 支 中 提交 更 新 后 的 提交 历史 



















































现在 ， Jessica, Josie 和 John 通知 集成 管理 员 服 务 器 上 的 featureA 及 featureBee 分 支 已 经 准备 好 ， 可 以 
并 入 主线 了 。 在 管理 员 完 成 集成 工作 后 ， 主 分 支 上 便 多 出 一 个 新 的 合并 提交 (5399e) , Hj fetch 命令 更 新 到 
本 地 后 ， 提 交 历 史 如 图 5.14 所 示 : 
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图 5.14: 合并 特性 分 支 后 的 Jessica 提交 历史 



















































































许多 开发 小 组 改 用 Git 就 是 因为 它 允 许多 个 小 组 间 并 行 工作 ， 而 在 稍 后 恰当 时 机 再 行 合并 。 通 过 共享 远程 
分 支 的 方式 ， 无 需 干扰 整体 项 目 代码 便 可 以 开展 工作 ， 因 此 使 用 Git 的 小 型 团队 间 协 作 可 以 变 得 非常 灵活 
e 以 上 工作 流程 的 时 序 如 图 5.15 所 示 ; 






































































































































5.2.4 公开 的 小 型 项 目 


























上 面 说 的 是 私有 项 目 协 作 ， 但 要 给 公开 项 目 作 贡献 ， 情 况 就 有 些 不 同 了 。 因 为 你 没有 直接 更 新 主 仓库 分 文 的 
权限 ， 得 寻求 其 它 方式 把 工作 成 果 交 给 项 目 维 护 人 。 下 面 会 介绍 两 种 方法 ， 第 一 种 使 用 git 托管 服务 商 提供 
的 仓库 复制 功能 ， 一 般 称 作 fork， 比 如 repo.or.cz 和 GitHub 都 文 持 这 样 的 操作 ， 而 且 许 多 项 目 管理 员 都 
希望 大 家 使 用 这 样 的 方式 。 男 一 种 方法 是 通过 电子 邮件 寄 送 文件 补丁 。 

但 不 管 哪 种 方式 ， 起 先 我 们 总 需要 克隆 原始 仓库 ， 而 后 创建 特性 分 支 开展 工作 。 基 本 工作 流程 如 下 : 











































































































































































































































































































$ git clone (url) 

$ cd project 

$ git checkout -b featureA 
$ (work) 

$ git commit 

$ (work) 


$ git commit 

































































你 可 能 想到 用 rebase -i 将 所 有 更 新 先 变 作 单 个 提交 ， 又 或 者 想 重 新 安排 提交 之 间 的 差异 补丁 ， 以 方便 项 
维护 者 审阅 一 有 关 交 互 式 衍 合 操作 的 细 市 见 第 六 章 。 
在 完成 了 特性 分 支 开发 ， 提 交 给 项 目 维护 者 之 前 ， 先 到 原始 项 目的 页 面 上 点 击 “Fork” 按 钮 ， 创 建 一 个 自己 
可 写 的 公共 仓库 (译注 : 即 下 面 的 url 部 分 ， 参照 后 续 的 例子 ， 应 该 是 git://githost/simplegit.git) 。 然 后 将 
此 仓库 添加 为 本 地 的 第 二 个 远 端 仓库 ， 姑 且 称 为 myfork: 













































































































































































$ git remote add myfork (url) 














H 


你 需要 将 本 地 更 新 推送 到 这 个 仓库 。 要 是 将 远 端 master 合并 到 本 地 再 推 回去 ， 还 不 如 把 整个 特性 分 支 推 上 
去 来 得 干脆 直接 。 而 且 ， 假 若 项 目 维护 者 未 采纳 你 的 贡献 的 话 (不 管 是 直接 合并 还 是 cherry pick) ， 都 不 用 
回 退 (rewind) ,的 master 分 支 。 但 车 维护 者 合并 或 cherry-pick 了 你 的 工作 ， 最 后 总 还 可 以 从 他 们 的 
更 新 中 同步 这 些 代 码 。 好 吧 ， 现 在 先 把 featureA 分 支 整 个 推 上 去 : 
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Jessica John Josie Server: featureA Server : featureBee 


git commit on A 







aum pusn OF ig Pair es Tealrecee 
ii LI d 





Jessica John Josie Server: featureA Server: featureBee 


图 5.15: 团队 间 协 作 工 作 流程 基本 时 序 


$ git push myfork featureA 


然后 通知 项 目 管理 员 ， 让 他 来 抓 取 你 的 代码 。 通 常 我 们 把 这 件 事 叫做 pull request。 可 以 直接 用 GitHub 
等 网 站 提供 的 "pull request" 按钮 自动 发 送 请 求 通知 ; 或 手工 把 git request-pull 命令 输出 结果 电邮 给 项 
目 管理 员 。 


request-pull 命令 接受 两 个 参数 ， 第 一 个 是 本 地 特性 分 支 开 始 前 的 原始 分 支 ， 第 二 个 是 请 求 对 方 来 抓 取 的 Git 





























Tr 
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仓库 URL (ETE: 即 下 面 myfork 所 指 的 ， 自 己 可 写 的 公共 仓库 ) 。 比 如 现在 Jessica 准备 要 给 John 发 一 个 
pull requst， 她 之 前 在 自己 的 特性 分 文 上 提交 了 两 次 更 新 ， 并 把 分 支 整个 推 到 了 服务 器 上 ， 所 以 运行 该 命令 
会 看 到 : 






















































































$ git request-pull origin/master myfork 
The following changes since commit ledee6b1d61823a2de3b09c160d7080b8d1b3a40: 
John Smith (1): 


added a new function 
are available in the git repository at: 
git://githost/simplegit.git featureA 
Jessica Smith (2): 
add limit to log function 


change log output to 30 from 25 


lib/simplegit.rb | 10 +++++++++- 


1 files changed, 9 insertions(*), 1 deletions(-) 





















































输出 的 内 容 可 以 直接 发 邮件 给 管理 者 ， 他 们 就 会 明日 这 是 从 哪 次 提交 开始 旁 支 出 去 的 ， 该 到 哪里 去 抓 取 新 的 

代码 ， 以 及 新 的 代码 增加 了 哪些 功能 等 等 。 
像 这 样 随时 保持 自己 的 master 分 支 和 官方 origin/master 同步 ， 并 将 自己 的 工作 限制 在 特性 分 支 上 的 做 法 ， 
既 方 便 又 灵活 ， 采 纳 和 丢弃 都 轻而易举 。 就 算 原 始 主 干 发 生变 化 ， 我 们 也 能 重新 衍 合 提 供 新 的 补丁 。 比 如 现在 
要 开始 第 二 项 特性 的 开发 ， 不 要 在 原来 已 推送 的 特性 分 支 上 继续 ， 还 是 按 原始 master 开始 : 



















































































































































































$ git checkout -b featureB origin/master 
$ (work) 

$ git commit 

$ git push myfork featureB 

$ (email maintainer) 


$ git fetch origin 















































ME, A^ B 两 个 符 性 分 文 各 不 相 扰 ， 如 同 竹 简 里 的 两 颗 豆 子 ， 队 列 中 的 两 个 补丁 ， 你 随时 都 可 以 分 别 从 头 
写 过 ， 或 者 衍 合 ， 或 者 修改 ， 而 不 用 担心 特性 代码 的 交叉 混杂 。 如 图 5.16 Bron: 


T sei 





















































图 5.16: featureB 以 后 的 提交 历史 











假设 项 目 管理 员 接纳 了 许多 别人 提交 的 补 本 后， 准备 要 采纳 你 提交 的 第 一 个 分 支 ， 却 发 现 因为 代码 基准 不 一 
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致 ， 合 并 工作 无 法 正确 干净 地 完成 。 这 就 需要 你 再 次 衍 合 到 最 新 的 origin/master， 解 决 相关 冲突 ， 然 后 重新 提 























交 你 的 修改 : 


$ git checkout featureA 
$ git rebase origin/master 


$ git push -f myfork featureA 




































































习 然 ， 这 会 重 写 提交 历史 ， 如 区 








图 5.17: featureA 重新 衍 合 后 的 提交 


A 
"E 




















注意 ， 此 时 推送 分 支 必须 使 用 -f 选项 〈 译 注 : 表示 force， 不 作 检 查 强制 重 写 ) 替换 远程 已 有 的 featureA 












































分 支 ， 因 为 新 的 commit 








非 原来 的 后 续 更 新 。 当 然 你 也 可 以 直接 推送 到 另 一 个 新 的 分 支 上 去 ， 比 如 称 作 





featureAv2 ° 

















































































































再 考虑 另 一 种 情形 ， 管 理 员 看 过 第 二 个 分 支 后 觉得 思路 新 颖 ， 但 想 请 你 改 下 具体 实现 。 我 们 只 需 以 当前 


























origin/master 分 支 为 基准 ， 
突 ， 按 要 求 





papi 














始 一 个 新 的 特性 分 文 featureBv2， 然 后 把 原来 的 features 的 更 新 拿 过 来 ， 解 决 冲 























新 实现 部 分 代码 ， 然 后 将 此 特性 分 支 推 送 上 去 : 








$ git checkout -b featureBv2 origin/master 


$ git merge --no-commit --squash featureB 


$ (change implementation) 
$ git commit 


$ git push myfork featureBv2 





这 里 的 --squash 选项 将 目标 分 支 上 的 所 有 更 改 全 拿 来 应 用 到 当前 分 支 上 ， 而 --no-commit 选项 告诉 Git 此 时 




















无 需 自 动 生 成 和 记录 ( 合 


























) 提交 。 这 样 ， 你 就 可 以 在 原来 代码 基础 上 ， 继 续 工 作 ， 直 到 最 后 一 起 提交 。 



























































好 了 ， 现 在 可 以 请 管理 员 抓 取 featureBv2 上 的 最 新 代码 了 ， 如 图 5.18 所 示 : 











Ea Es] 
T etie (m ) 


NES a 
(ees ) 


图 5.18: featureBv2 之 后 的 提交 历史 
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5.2.5 公开 的 大 型 项 目 


























许多 大 型 项 目 都 会 立 有 

















THE, (KDA 









































AFORE EDT, Süd 




















o 





























Scott Chacon Pro Git 


























我 们 来 看 具体 例子 






























































整个 工作 流程 类 似 上 男 



























































2 目 都 允许 通过 开发 者 邮 
而 不 同 之 处 在 于 如 何 提交 这 些 补丁 。 不 需 
































要 创建 自己 可 写 的 公共 仓库 






































Tt 
































$ git checkout -b topicA 
$ (work) 

$ git commit 

$ (work) 


$ git commit 






































邮件 的 方式 依次 发 送 到 
































如 此 一 番 后 ， 有 了] 




















个 提交 要 发 到 




































































后 作为 附件 发 送 。 每 个 提交 都 会 封装 ; 
是 提交 消息 〈 译 注 : 额外 有 前 级 ， 

































































受 补丁 时 仍 可 保留 原来 的 提交 消息 ， 





$ git format-patch -M origin/master 
0001-add-limit-to-log-function.patch 
0002-changed-log-output-to-30-from-25. patch 





























format-patch 命令 依次 创建 补 J 
提交 。 我 们 来 看 看 补丁 文件 的 内 容 











$ cat 0001-add-limit-to-log-function.patch 

From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001 
From: Jessica Smith <jessica@example.com> 

Date: Sun, 6 Apr 2008 10:17:23 -0700 

Subject: [PATCH 1/2] add limit to log function 


Limit log functionality to the first 20 


lib/simplegit.rb | 2 +- 


1 files changed, 1 insertions(+), 1 deletions(-) 


diff --git a/lib/simplegit.rb b/lib/simplegit.rb 
index 76f47bc..f9815fl 100644 


--- a/lib/simplegit.rb 
+++ b/lib/simplegit.rb 


@@ -14,7 +14,7 @@ class SimpleGit 


end 


def log(treeish = 'master') 
- command("git log #{treeish}") 
* command("git log -n 20 Z(treeish)") 
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NS 





R 务 器 ， 你 只 需 将 每 


] 可 以 用 git format-patch 
.patch 后 组 的 mbox XH 
p 件 内 容 包含 补丁 了 
看 接 下 来 的 例子 : 





的 - 选项 允许 cit 检查 























成 mbox 格式 的 文件 然 


























F, 但 
EMA Git 








封 邮 件 ， 邮 件 标题 就 
。 这 种 方式 的 妙 处 在 于 接 




















pu 
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和 对 文件 重 命名 的 



































Scott Chacon Pro Git 5.2 节 为 项 目 作 贡献 








end 


def 1s tree(treeish = 'master') 


1.6.2.rc1.20.g8c5b.dirty 

























































































如 果 有 额外 信息 需要 补充 ， 但 又 不 想 放 在 提交 消息 中 说 明 ， 可 以 编辑 这 些 补 丁 文件 ， 在 第 一 个 --- 行 之 前 
添加 说 明 ， 但 不 要 修改 下 面 的 补丁 正文 ， 比 如 例子 中 的 Limit 10g functionality to the first 20 部 分 。 这 样 ， 其 
它 开 发 者 能 阅读 ， 但 在 采纳 补丁 时 不 会 将 此 合并 进来 。 
你 可 以 用 邮件 客户 端 软 件 发 送 这 些 补丁 文件 ， 也 可 以 直接 在 命令 行 发 送 。 有 些 所 谓 智能 的 邮件 客户 端 软件 会 
自作 主张 帮 你 调整 格式 ， 所 以 粘贴 补丁 到 邮件 正文 时 ， 有 可 能 会 丢失 换行 符 和 郑 干 空格 。Git 提供 了 一 个 通过 
MAP 发 送 补丁 文件 的 工具 。 接 下 来 我 会 演示 如 何 通过 Gmail 的 IMAP 服务 器 发 送 。 另 外 , 在 Git 源 代 码 中 
有 个 Documentation/SubmittingPatches 文件 ， 可 以 仔细 读 读 ， 看 看 其 它 邮件 程序 的 相关 导 引 。 

先 在 ^/.gitconfig 文件 选项 都 可 用 git config 命令 分 别 设置 ， 当 然 直接 编辑 文件 添 
加 以 下 内 容 更 便捷 : 
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[imap] 
folder = "[Gmail]/Drafts" 
host = imaps://imap.gmail.com 
user = user@gmail.com 
pass = p4sswOrd 
port = 993 


sslverify = false 










































































如 果 你 的 IMAP 服务 器 没有 启用 SSL， 就 无 需 配 置 最 后 那 两 行 ， host 应 该 以 imap:// 开头 而 不 再 是 有 
s 的 inaps://。 保 存 配置 文件 后 ， 就 能 用 git send-email 命令 把 补丁 作为 邮件 依次 发 送 到 指定 的 IMAP 服务 器 
的 文件 夹 中 GFE: 这 里 就 是 Gmail 的 [Gmail]/prafts 文件 夹 。 但 如 果 你 的 语言 设置 不 是 英文 ， 此 处 的 文件 夹 
Drafts 字样 会 变 为 对 应 的 语言 。) 






















































































sw 











FH 
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$ git send-email *.patch 

0001-added-limit-to-log-function. patch 
0002-changed-log-output-to-30-from-25. patch 

Who should the emails appear to be from? [Jessica Smith <jessica@example.com> | 
Emails will be sent from: Jessica Smith <jessica@example.com> 

Who should the emails be sent to? jessica@example.com 


Message-ID to be used as In-Reply-To for the first email? y 














Bi RH, Git 会 根据 每 个 补丁 依次 输出 类 似 下 面 的 日 志 : 








IT 

















(mbox) Adding cc: Jessica Smith «jessica eexample.com» from 
Mine 'From: Jessica Smith <jessica@example.com>' 

OK. Log says: 

Sendmail: /usr/sbin/sendmail -i jessica@example.com 

From: Jessica Smith <jessica@example.com> 


To: jessica@example.com 
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Subject: [PATCH 1/2] added limit to log function 

Date: Sat, 30 May 2009 13:29:15 -0700 

Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com> 
X-Mailer: git-send-email 1.6.2.rcl.20.g8c5b. dirty 

In-Reply-To: <y> 


References: <y> 


Result: OK 











最 后 ， 到 Gmail 上 打开 Drafts 文件 夹 ， 编 辑 这 些 邮 件 ， 修 改 收 件 人 地 址 为 邮件 列表 地 址 ， 另 外 给 要 抄 送 






































的 人 也 加 到 cc 列表 





， 最 后 发 送 。 











5.2.6 小 结 
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本 市 主要 介绍 了 常见 Git 项 目 协作 的 工作 流程 ， 还 有 一 些 帮 助 处 理 这 些 工 作 的 命令 和 工 
看 看 如 何 维护 Git 项 目 ， 并 成 为 一 个 合格 的 项 目 管理 员 ， 或 是 集成 经 理 。 













































































5.3 项 目的 管理 






































既然 是 相互 协作 ， 在 贡献 代码 的 同时 ， 也 免不了 要 维护 管理 自己 的 项 目 。 像 是 怎 么 处 理 别人 用 






























































Lo Be PRET 


format-patch 





HE 





























成 的 补丁 ， 或 是 集成 远 端 仓 库 上 某 个 分 文 上 的 变化 等 等 。 但 无 论 是 管理 代码 仓库 ， 还 是 帮忙 
， 都 需要 同 贡 献 者 约定 某 种 长 期 可 持续 的 工作 方式 。 


















































5.3.1 使 用 特性 分 支 进行 工作 














核 收 到 的 补 



































如 果 想 要 集成 新 的 代码 进来 ， 最 好 局 限 在 特性 分 文 上 做 。 临 时 的 特性 分 支 可 以 让 你 随意 尝试 ， 进 ; 












































如 碰 上 无 法 正常 工作 的 补丁 ， 可 以 先 搁 在 那 边 ， 直 到 有 时 间 仔 细 核 查 修复 为 上 。 创建 的 分 文 可 以 用 




























































































关键 字 命名 ， 比 如 ruby client 或 者 其 它 类 似 的 描述 性 词语 ， 以 帮助 将 来 回忆 。Git 项 目 本 身 还 时 常 把 分 支 名 


























































































































称 分 置 于 不 同 命名 空间 下 ， 比 如 sc/ruby client 就 说 明 这 是 sc 这 个 人 贡献 的 。 现 在 从 当前 主干 分 支 为 基础 ， 











新 建 临 时 分 支 : 














$ git branch sc/ruby client master 























另外 ， 如 果 你 硕 望 立即 转 到 分 文 上 去 工作 ， 可 以 用 checkout -b: 








$ git checkout -b sc/ruby client master 
































y 





好 了 ， 现 在 已 经 准备 妥当 ， 可 以 试 着 将 别人 贡献 的 代码 合并 进来 了 。 之 后 评估 一 下 有 没有 问题 ， 
ENE 的 要 入 主干 。 

















































































































5.3.2 采纳 来 自 邮 件 的 补丁 
































再 决定 
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Hx 



















































































如 果 收 到 一 个 通过 电邮 发 来 的 补丁 ， 你 应 该 先 把 它 应 用 到 特性 分 文 上 进行 评 佑 。 有 两 种 应 用 补丁 的 方法 : uit 






























































apply 或 git am ° 
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使 用 apply 命令 应 用 补丁 












































如 果 收 到 的 补丁 文件 是 用 git diff 或 由 其 它 Unix 的 diff 命令 生成 ， 就 该 用 git apply 命令 来 应 用 补丁 。 
假设 补丁 文件 存在 /tmp/patch-ruby-client.patch, 可 以 这 样 运 












































di 


$ git apply /tmp/patch-ruby-client.patch 







































































这 会 修改 当前 工作 目录 下 的 文件 ， 效 果 基 本 与 运行 patch -pl 打 补 丁 一 样 ， 但 它 更 为 严格 ， 且 不 会 出 现 混 
乱 。 如 果 是 eit aire 格式 描述 的 补丁 ， 此 命令 还 会 相应 地 添加 ， 删 除 ， 重 命名 文件 。 当 然 ， 普 通 的 patch 命令 
是 不 会 这 么 做 的 。 另 外 请 注意 ，git apply 是 一 个 事务 性 操作 的 命令 ， 也 就 是 说 ， 要 么 所 有 补丁 都 打上 去 ， 要 么 
全 部 放弃 。 所 以 不 会 出 现 patch 命令 那样 ， 一 部 分 文件 打上 了 补丁 而 另 一 部 分 却 没有 ， 这 样 一 种 不 上 不 下 的 修 
订 状 态 。 所 以 总 的 来 说 ，git apply 要 比 patch 严谨 许多 。 因 为 仅仅 是 更 新 当前 的 文件 ， 所 以 此 命令 不 会 自动 生 
成 提交 对 象 ， 你 得 手工 缓存 相应 文件 的 更 新 状态 并 执行 提交 命令 。 
在 实际 打 补 丁 之 前 ， 可 以 先 用 eit apply -check 查看 补丁 是 否 能 够 干净 顺利 地 应 用 到 当前 分 支 中 : 
















































































































































































































































































































































































$ git apply --check 0001-seeing-if-this-helps-the-gem.patch 
error: patch failed: ticgit.gemspec:l 


error: ticgit.gemspec: patch does not apply 





















































如 果 没 有 任何 输出 ， 表 示 我 们 可 以 顺利 采纳 该 补 本 。 如 果 有 问题 ， 除 了 报告 错误 信息 之 外 ， 该 命令 还 会 返 世 
一 个 非 零 的 状态 ， 所 以 在 shell 脚本 里 可 用 于 检测 状态 。 



























































使 用 am 命令 应 用 补丁 
































uu 












































x 
IX 


果 贡 献 者 也 用 Git， 且 擅 于 制作 format-patcn 补丁 ， 那 你 的 合并 工作 将 会 非常 轻松 。 因 为 这 些 补 丁 中 除了 
文件 内 容 差异 外 ， 还 包含 了 作者 信息 和 提交 消息 。 所 以 请 鼓励 贡献 者 用 format-patch 生成 补丁 。 对 于 传统 的 
diff 命令 生成 的 补丁 ， 则 只 能 用 sit apply 处 理 。 
对 于 format-patch 制作 的 新 式 补丁 ， 应 当 使 用 eit am 命令 。 从 技术 上 来 说 ，git an 能 够 读 取 mbox 格式 的 文 
件 。 这 是 种 简单 的 纯 文 本 文件 ， 可 以 包含 多 封 电邮 ， 格 式 上 用 From 加 空格 以 及 随便 什么 辅助 信息 所 组 成 的 行 
作为 分 隔行 ， 以 区 分 每 封 邮 件 ， 就 像 这 检 











































































































































































































































































































Tr 





From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001 
From: Jessica Smith <jessica@example.com> 

Date: Sun, 6 Apr 2008 10:17:23 -0700 

Subject: [PATCH 1/2] add limit to log function 


Limit log functionality to the first 20 




















这 是 format-patch 命令 输出 的 开头 几 行 ， 也 是 一 个 有 效 的 mbox 文件 格式 。 如 果 有 人 用 git send-email 给 你 
发 了 一 个 补丁 ， 你 可 以 将 此 邮件 下 载 到 本 地 ， 然 后 运行 git am 命令 来 应 用 这 个 补丁 。 如 果 你 的 邮件 客户 端 能 
将 多 封 电 邮 导 出 为 mbox 格式 的 文件 ， 就 可 以 用 eit am 一 次 性 应 用 所 有 导出 的 补丁 。 

如 果 贡 献 者 将 format-patch 生成 的 补丁 文件 上 传 到 类 似 Request Ticket 一 样 的 任务 处 理 系统 ， 那 么 可 以 先 
下 载 到 本 地 ， 继 而 使 用 eit am 应 用 该 补丁 : 
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$ git am 0001-limit-log-function.patch 


Applying: add limit to log function 
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你 会 看 到 它 被 干净 地 应 用 到 本 地 分 支 ， 并 自动 创建 了 新 的 提交 对 象 。 作 者 信息 取 自 邮件 头 From 和 Date, $e 
区 消息 则 取 自 subject 以 及 正文 中 补丁 之 前 的 内 容 。 来 看 具体 实例 ， 采 纳 之 前 展示 的 那个 mbox 电邮 补丁 后 ， 
最 新 的 提交 对 象 为 : 
$ git log --pretty=fuller -1 
commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 
Author: Jessica Smith <jessica@example.com> 
AuthorDate: Sun Apr 6 10:17:23 2008 -0700 
Commit: Scott Chacon <schacon@gmail.com> 
CommitDate: Thu Apr 9 09:19:06 2009 -0700 

add limit to log function 

Limit log functionality to the first 20 

Commit 部 分 显示 的 是 采纳 补丁 的 人 ， 以 及 采纳 的 时 间 。 而 Author 部 分 则 显示 的 是 原作 者 ， 以 及 创建 补丁 的 
时 间 。 

有 时 ， 我 们 也 会 遇 到 打 不 上 补丁 的 情况 。 这 多 半 是 因为 主干 分 支 和 补丁 的 基础 分 支 相 差 太 远 ， 但 也 可 能 是 因 
为 某 些 依赖 补丁 还 未 应 用 。 这 种 情况 下 ，git am 会 报错 并 询问 该 怎么 做 : 











$ git am 0001-seeing-if-this-helps-the-gem.patch 


Applying: seeing if this helps the gem 


error: patch failed: ticgit.gemspec:l 


error: ticgit.gemspec: patch does not apply 
Patch failed at 0001. 


When you have resolved this problem run "git am --resolved". 





If you would prefer to skip this patch, instead run "git am --skip'. 


To restore the original branch and stop patching run "git am --abort". 










































































































































































































































































































































































Git 会 在 有 冲突 的 文件 里 加 入 冲突 解决 标记 ， 这 同 合并 或 衍 合 操 作 一 样 。 解 决 的 办 法 也 一 样 ， 先 编辑 文件 消 
除 冲突 ， 然 后 暂 存 文件 ， 最 后 运行 git am --resolved 提交 修正 结果 : 
$ (fix the file) 
$ git add ticgit.gemspec 
$ git am --resolved 
Applying: seeing if this helps the gem 

如 果 想 让 Git 更 智能 地 处 理 冲 突 ， 可 以 用 -3 选项 进行 三 方 合 并 。 如 果 当 前 分 支 未 包含 该 补丁 的 基础 代码 
或 其 祖先 ， 那 么 三 方 合并 就 会 失败 ， 所 以 该 选项 默认 为 关闭 状态 。 一 般 来 说 ， 如 果 该 补丁 是 基于 某 个 公开 的 提 
交 制 作 而 成 的 话 ， 你 总 是 可 以 通过 同步 来 获取 这 个 共同 祖先 ， 所 以 用 三 方 合 并 选项 可 以 解决 很 多 麻烦 : 
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$ git am -3 0001-seeing-if-this-helps-the-gem.patch 


Applying: seeing if this helps the gem 


error: patch failed: ticgit.gemspec:l 


error: ticgit.gemspec: patch does not apply 


Using index info to reconstruct a base tree... 


Falling back to patching base and 3-way merge... 


No changes -- Patch already applied. 



































































































































































































































5.3 mH 








的 管理 

































































































































































































































































































































































































































































像 上 面 的 例子 ， 对 于 打 过 的 补丁 我 又 再 打 一 遍 ， 自 然 会 产生 冲突 ， 但 因为 加 上 了 -3 选项 ， 所 以 它 很 聪明 地 
告诉 我 ， 无 需 更 新 ， 原 有 的 补丁 已 经 应 用 。 

对 于 一 次 应 用 多 个 补丁 时 所 用 的 mbox 格式 文件 ， 可 以 用 am 命令 的 交互 模式 选项 -i:， 这 样 就 会 在 打 每 个 补 

前 停 住 ， 询 问 该 如 何 操作 : 
$ git am -3 -i mbox 
Commit Body is: 
ME P iares 
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept a11 

在 多 个 补丁 要 打 的 情况 下 ， 这 是 个 非常 好 的 办 法 ， 一 方面 可 以 预览 下 补丁 内 容 ， 同 时 也 可 以 有 选择 性 的 接纳 
或 跳 过 某 些 补丁 。 

打 完 所 有 补丁 后 ， 如 果 测 试 下 来 新 特性 可 以 正常 工作 ， 那 就 可 以 安心 地 将 当前 特性 分 文 合并 到 长 期 分 文中 去 
Ta o 
5.3.3 和 检 出 远程 分 支 

如 果 贡 献 者 有 自己 的 Git 仓库 ， 并 将 修改 推送 到 此 仓库 中 ， 那 么 当 你 拿 到 仓库 的 访问 地 址 和 对 应 分 文 的 名 
称 后 ， 就 可 以 加 为 远程 分 文 ， 然 后 在 本 地 进行 合并 。 

比如 ，Jessica 发 来 一 封 邮件 ， 说 在 她 代码 库 中 的 ruby-client 分 文 上 已 经 实现 了 某 个 非常 棒 的 新 功能 ， 和 希 
望 我 们 能 帮忙 测试 一 下 。 我 们 可 以 先 把 她 的 仓库 加 为 远程 仓库 ， 然 后 抓 取 数 据 ， 完 了 再 将 她 所 说 的 分 支 检 出 到 
本 地 来 测试 : 


$ git remote add jessica git://github.com/jessica/myproject.git 


$ git fetch jessica 


$ git checkout -b rubyclient jessica/ruby-client 











































































































































































































































































































































































































车 是 不 久 她 又 发 来 邮件 ， 说 还 有 个 很 棱 的 功能 实现 在 另 一 分 支 上 ， 那 我 们 只 需 重新 抓 取 下 最 新 数据 ， 然 后 检 
出 那个 分 文 到 本 地 就 可 以 了 ， 无 需 重复 设置 远程 仓库 。 

这 种 做 法 便于 同 别人 保持 长 期 的 合作 关系 。 但 前 提 是 要 求 贡献 者 有 自己 的 服务 器 ， 而 我 们 也 需要 为 每 个 人 建 
一 个 远程 分 文 。 有 些 页 献 者 提交 代码 补丁 并 不 是 很 频繁 ， 所 以 通过 邮件 接收 补丁 效率 会 更 高 。 同 时 我 们 自己 也 
不 会 和 厦 望 建 上 百 来 个 分 文 ， 却 只 从 每 个 分 支取 一 两 个 补丁 。 但 若是 用 脚本 程序 来 管理 ， 或 直接 使 用 代码 仓库 托 
管 服 务 ， 就 可 以 简化 此 过 程 。 当 然 ， 选 择 何 种 方式 取决 于 你 和 贡献 者 的 喜好 。 
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使 用 远程 分 支 的 另外 一 个 好 处 是 能 够 得 到 提交 历史 。 不 管 代码 合并 是 不 是 会 有 问题 ， 至 少 我 们 知道 该 分 支 的 
历史 分 义 点 ， 所 以 默认 会 从 共同 祖先 开始 自动 进行 三 方 合并 ， 无需 -3 选项 ， 也 不 用 像 打 补 丁 那 样 祈祷 存在 共 
同 的 基准 点 。 

如 果 只 是 临时 合作 ， 只 需 用 eit pull 命令 抓 取 远 程 仓库 上 的 数据 ， 合 并 到 本 地 临时 分 支 就 可 以 了 。 一 次 性 的 
抓 取 动作 自然 不 会 把 该 仓库 地 址 加 为 远程 仓库 。 


























$ git pull git://github.com/onetimeguy/project.git 


From git://github.com/onetimeguy/project 


* branch HEAD 


Merge made by recursive. 


5.3.4 


-» FETCH HEAD 


决断 代码 取信 











现在 特性 分 支 上 已 合 





好 了 贡献 者 的 代码 ， 

















要 合并 到 主 


于 的 是 


一 般 我 们 会 先 看 下 ，1 





























哪些 代码 ， 从 而 
竺 性 分 支 上 都 有 哪些 新 增 











是 时 候 决 断 取 舍 了 。 本 市 将 




















理解 它们 


























到 底 


H 

















改 了 些 什么 ， 是 否 真 的 要 







































































H 














个 补丁 的 提交 信息 ， 


$ git log contrib --not ma 








DAFA 


ster 


commit 5b6235bd297351589efc4d73316f0a68d484f118 


Author: Scott C 
Fri Oct 


hacon <scha 
Date: 24 09:53:5 


seeing if this helps t 
commit 7482e0d16d04bea79d0 
Author: Scott C 
Mon Oct 22 19:38:3 





hacon <scha 


Date: 


updated the gemspec to 


con@gmail.com> 
9 2008 -0700 


he gem 
dba8988cc78df655f 16a0 
con@gmail.com> 


6 2008 -0700 


hopefully work better 
























































--not 选项 指定 要 


LE 


并 





入 。 


顾 一 些 之 前 学 过 的 命令 ， 以 看 清 将 


























的 提交 。 比 如 在 contrib 特性 分 支 上 打 了 
蔽 的 分 支 master， 这 样 训 























个 补丁 ， 仅 查看 这 

















会 剔除 重复 的 提交 历史 ; 




























































































































































































































































































































































































































































































































































































还 可 以 查看 每 次 提交 的 具体 修改 。 请 牢记 ,在 sit ios 后 加 -p 选项 将 展示 每 次 提交 的 内 容 差 异 。 

如 果 想 看 当前 分 支 同 其 他 分 支 合并 时 的 完整 内 容 差 异 ， 有 个 小 窍门 : 
$ git diff master 

虽然 能 得 到 差异 内 容 ， 但 请 记 住 ， 结 果 有 可 能 和 我 们 的 预期 不 同 。 一 旦 主干 master 在 特性 分 支 创建 之 后 有 
所 修改 ， 那 么 通过 ait 命令 来 比较 的 ， 是 最 新 主干 上 的 提交 快照 。 显 然 ， 这 不 是 我 们 所 要 的 。 比 方 在 master 
分 支 中 某 个 文件 里 添 了 一 行 ， 然 后 运行 上 面 的 命令 ， 简 单 的 比较 最 新 快照 所 得 到 的 结论 只 能 是 ， 特 性 分 支 中 删 
除了 这 一 行 。 

这 个 很 好 理解 : 如果 master 是 特性 分 支 的 直接 祖先 ， 不 会 产生 任何 问题 ， 如 果 它 们 的 提交 历史 在 不 同 的 分 
又 上 上， 那么 产生 的 内 容 差 异 ， 看 起 来 就 像 是 增加 了 特性 分 文 上 的 新 代码 ， 同 时 删除 了 master 分 支 上 的 新 代 
fH e 

实际 上 我 们 真正 想 要 看 的 ， 是 新 加 入 到 特性 分 文 的 代码 ， 也 就 是 合并 时 会 并 入 主干 的 代码 。 所 以 ， 谁 确 地 
讲 ， 我 们 应 该 比较 特性 分 文 和 它 同 master 分 支 的 共同 祖先 之 间 的 差异 。 
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我 们 可 以 手工 定位 它们 的 共同 祖先 ， 然 后 与 之 比较 : 











$ git merge-base contrib master 
36c'7dba2c95e6bbb78dfa822519ecfec6elca649 
$ git diff 36c7db 
































日 这 么 做 很 麻烦 ， 所 以 Git 提供 了 便捷 的 ... 语法 。 对 于 diff 命令 ,可 以 把 ... 加 在 原始 分 文 (拥有 共 
同 祖先 ) 和 当前 分 支 之 间 : 



































$ git diff master...contrib 























现在 看 到 的 ， 就 是 实际 将 要 引入 的 新 代码 。 这 是 一 个 非常 有 用 的 命令 ， 应 该 牢记 。 








5.3.5 代码 集成 


一 候 特 性 分 文 准 备 停 当 ， 接 下 来 的 问题 就 是 如 何 集成 到 更 靠近 主线 的 分 支 中 。 此 外 还 要 考虑 维护 项 目的 总 体 
步骤 是 什么 。 虽然 有 很 多 选择 ， 不 过 我 们 这 里 只 介绍 其 中 一 部 分 。 





































































































般 最 简单 的 情形 ， 是 在 master 分 支 中 维护 稳定 代码 ， 然 后 在 特性 分 支 上 开发 新 功能 ， 或 是 审核 测试 别人 
贡献 的 代码 ， 接 着 将 它 并 入 主干 ， 最 后 删除 这 个 特性 分 支 ， 如 此 反复 。 来 看 示例 ， 假 设 当前 代码 库 中 有 两 个 分 
x, 分 别 为 ruby_client 和 php client, 如 图 5.19 所 示 o 然后 先 把 ruby client 合 yt CT, BRE php client, 


最 后 的 提交 历史 如 图 5.20 所 示 。 
-© 


MC 





















































c 

























































































E 5.19: 多 个 特性 分 支 
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图 5.20: 合并 特性 分 支 之 后 


这 是 最 简单 的 流程 ， 所 以 在 处 理 大 一 些 的 项 目 时 可 能 会 有 问题 。 











对 于 大 型 项 目 ， 至 少 需 要 维护 两 个 长 
先 并 入 develop 分 支 (图 5:22 中 的 c8) i 


























master 分 支 快 进 到 稳定 点 (图 5.23 
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IEA] cs) 





期 分 支 master 和 develop。 新 代码 ( 


经 过 一 














个 阶段 ， 确认 develop 








。 而 了 


F 时 这 两 个 分 支 都 会 被 推送 到 公 


= 
OO) 


cece 


ruby_client 


图 5.21: 特性 分 支 合并 前 





ruby_client 


图 5.22: 特性 分 支 合并 后 





Scott Chacon Pro Git 





图 5.21 中 的 ruby client) 4 














的 代码 已 稳定 到 可 发 行 时 ， 再 














的 代码 库 。 


mu 




















ES 
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这 样 ， 在 人 们 克隆 仓库 时 就 有 两 种 选择 : 














最 前 沿 的 新 特性 。 








你 也 可 以 扩展 这 个 概念 ， 先 将 所 有 新 代码 
develop 2] X. ° MAIR, XERIBIESSS— 7), 405 



































既 可 检 出 最 新 稳定 版 本 ， 确 保 ] 




















1 该 分 支 稳 定 下 来 


























5.3 节 项 目的 管理 





























发 版 本 ， 试 用 























六 通过 测试 后 ， 再 并 入 
































这 些 代码 确实 可 以 正常 了 
































大 项 目的 合并 流程 








Git 项 目 本 身 有 四 个 长 期 分 支 ; 










































































到 公共 仓库 ， 以 供 其 他 人 试用 

















-0-6 
\@- @- Ez] 
-加 -CE 


管理 复杂 的 并 行 贡献 














仍 需 改进 的 特性 可 以 先 并 入 pu 分 文 。 
足够 稳定 的 特性 也 A master ° 所 以 一 般 来 说 ， master 始终 是 在 快 进 ， next 1H 

















合 ， 如 图 5.25 Br: 


























已 经 足够 稳定 ， 可 以 放心 并 入 主干 分 支 发 布 。 

















FE 的 next 分 支 、 用 于 合并 
F 除 错 维 护 的 maint 分 支 (maint 取 
4px (如 图 5.24 所 




















于 发 布 的 master 分 支 、 用 了 
乃 需 改进 特性 的 pu 分 支 (pu 是 proposed updates 的 缩写 ) ， 以 及 用 了 
H maintenance) 。 维 护 者 可 以 按照 之 前 介 
示 ) ， 然 后 测试 评估 ， 看 哪些 特性 能 稳定 了 


























绍 的 方法 ， 将 贡献 者 的 代码 引入 为 不 同 的 特性 
的 特性 可 以 并 入 next P, 然后 再 推送 





























[L 作 ， 哪 些 还 需 改进 























到 它们 完全 稳定 后 









































TH, WU pu 则 是 频繁 








E 需 保留 分 支 索 引 ， 放 心 删除 好 了 。Git 项 
户 除 错 补丁 。 所 以 克隆 Git 项 


并 入 master 后 的 特性 分 文 ， 已 经 
义 最 近 一 次 发 行 版 为 基础 分 化 而 来 的 ， 









































[ 作 相 当 长 一 段 时 间 ， 那 就 有 理由 相信 它 





















































S next ^x, 4 








N 
CH R 










































































有 序 地 并 入 第 三 方 贡献 。 











上 ， 或 是 贡献 代码 。 而 维护 者 则 通 ; 











过 检 出 不 同 分 支 可 以 了 解 各 自 进展 ， 
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图 5.25: 将 特性 并 入 长 期 分 支 


衍 合 与 挑 拒 (cherry-pick) 的 流程 

















一 些 维护 者 更 喜欢 衍 合 或 者 挑 拣 贡 献 者 的 代码 ， 而 不 是 简单 的 合并 ， 因 为 这 样 能 够 保持 线性 的 提交 历史 。 如 
果 你 完成 了 一 个 特性 的 开发 ， 并 决定 将 它 引 入 到 主干 代码 中 ， 你 可 以 转 到 那个 特性 分 支 然后 执行 衍 合 命 令 ， 好 
在 你 的 主干 分 支 上 (也 可 能 是 develop 分 支 之 类 的 ) 重新 提交 这 些 修 改 。 如 果 这 些 代 码 工作 得 很 好 ， 你 就 可 以 快 
进 naster 分 文 ， 得 到 一 个 线性 的 提交 历史 。 

男 一 个 引入 代码 的 方法 是 挑 拒 。 挑 拒 类 似 于 针对 某 次 特定 提交 的 衍 合 。 它 首先 提取 某 次 提交 的 补丁 ， 然 后 试 
着 应 用 在 当前 分 支 上 。 如 果 某 个 特性 分 支 上 有 多 个 commits， 但 你 只 想 之 一 就 可 以 使 用 这 种 方法 。 也 
能 仅仅 是 因为 你 喜欢 用 挑 拣 ， 讨 厌 衍 合 。 假 设 你 有 一 个 类 似 图 5.26 的 工程 。 


















































































































































en 
> 
hi 

























































































图 5.26: kde (cherry-pick) 之 前 的 历史 








如 果 你 希望 拉 取 e43a6 到 你 的 主干 分 支 ， 可 以 这 样 : 








$ git cherry-pick e43a6fd3e94888d767779ad79fb568ed180e5fcdf 
Finished one cherry-pick. 
[master]: created a0a41a9: "More friendly message when locking the index fails." 


3 files changed, 17 insertions(*), 3 deletions(-) 























这 将 会 引入 e43a6 的 代码 ， 但 是 会 得 到 不 同 的 SHA-1 值 ， 因 为 应 用 日 期 不 同 。 现 在 你 的 历史 看 起 来 像 图 5.27. 
现在 ， 你 可 以 删除 这 个 特性 分 支 并 丢弃 你 不 想 引 入 的 那些 commit o 
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图 5.27: 挑 拒 (cherry-pick) 之 后 的 历史 


5.3.6 给 发 行 版 签名 


尔 可 以 删除 上 次 发 布 的 版 本 并 重新 打 标签 ， 也 可 以 像 第 二 章 所 说 的 那样 建立 一 个 新 的 标签 。 如 果 你 决定 以 维 
护 者 的 身份 给 发 行 版 签名 ， 应 该 这 样 做 : 





















































$ git tag -s v1l.5 -m 'my signed 1.5 tag’ 
You need a passphrase to unlock the secret key for 
user: "Scott Chacon <schacon@gmail.com>" 


1024-bit DSA key, ID F721C45A, created 2009-02-09 








完成 签名 之 后 ， 如 何 分 发 PGP 公 钥 (public key) 是 个 问题 。 QFE: 分 发 公 钥 是 为 了 验证 标签 ) 。 还 
好 ，Git 的 设计 者 想到 了 解决 办 法 : 可 以 把 key (WEAH) 作为 blob 变 量 写 入 Git 库 ， 然 后 把 它 的 内 容 直 接 写 在 
标签 里 。gpg --list-keys 命 令 可 以 显示 出 你 所 拥有 的 key: 









































T 
























































$ gpg --list-keys 

/Users/schacon/.gnupg/pubring. gpg 

pub 1024D/F721C45A 2009-02-09 [expires: 2010-02-09] 
uid Scott Chacon <schacon@gmail.com> 


sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09] 




















然后 ， 导 出 key 的 内 容 并 经 由 管道 符 传递 给 git hash-object， 之 后 钥匙 会 以 blob 类 型 写 入 Git 中 ， 最 后 返回 这 个 
blob 量 的 SHA-1 值 : 

































































$ gpg -a --export F721C45A | git hash-object -w --stdin 
659ef797d181633c87ec71ac3f9ba29fe5775b92 




















现在 你 的 Git 已 经 包含 了 这 个 key 的 内 容 了 ， 可 以 通过 不 同 的 SHA-1 值 指定 不 同 的 key 来 创建 
































$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe57775b92 
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在 运行 sit push --tags 命 令 之 后 ， maintainer-pgp-pub 标 签 就 会 公布 给 所 有 人 如 果 有 人 想 要 校 验 标签， E 
使 用 如 下 命令 导入 你 的 key: 






































$ git show maintainer-pgp-pub | gpg --import 






































人 们 可 以 用 这 个 key 校 验 你 签名 的 所 有 标签 。 另 外 ， 你 也 可 以 在 标签 信息 里 写 入 一 个 操作 向 导 ， 用 户 只 需要 
运行 fit show <tag> 查 看 标签 信息 ， 然 后 按照 你 的 向 导 就 能 完成 校 验 。 






















































































5.3.7 生成 内 部 版 本 号 


因为 Git 不 会 为 每 次 提交 自动 附加 类 似 ”v123 ”的 递增 序列 ， 所 以 如 果 你 想 要 得 到 一 个 便于 理解 的 提交 号 可 
以 运行 st deserite 命 令 。Git 将 会 返回 一 个 字符 串 ， 由 三 部 分 组 成 ， 最 近 一 次 标定 的 版 本 号 ， 加 上 自 那 次 标定 
之 后 的 提交 次 数 ， 再 加 上 一 段 SHA-1 值 of the commit you' re describing: 


















































H 













































































$ git describe master 


v1.6.2-rc1-20-g8c5b85c 












































这 个 字符 串 可 以 作为 快照 的 名 字 ， 方 便 人 们 理解 。 如 果 你 的 Git 是 你 自己 下 载 源码 然后 编译 安装 的 ， 你 会 发 
现 git --version 命 令 的 输出 和 这 个 字符 串 差 不 多 。 如 果 在 一 个 刚刚 打 完 标 签 的 提交 上 运行 describe 命 令 ， 只 会 得 
到 这 次 标定 的 版 本 号 ， 而 没有 后 面 两 项 信息 。 

git describe 命 令 只 适用 于 有 标注 的 标签 〈 通 过 -a 或 者 -s 选 项 创建 的 标签 ) ， 所 以 发 行 版 的 标签 都 应 该 是 带 有 
标注 的 ， 以 保证 git describe 能 够 正确 的 执行 。 你 也 可 以 把 这 个 字符 串 作为 checkout 或 者 show 命 令 的 目标 ， 因 为 他 
们 最 终 都 依赖 于 一 个 简短 的 SHA-1 值 ， 当 然 如 果 这 个 SHA-1 值 失效 他 们 也 跟着 失效 。 最 近 Linux 内 核 为 了 保证 
SHA-1 值 的 唯一 性 ， 将 位 数 由 8 位 扩展 到 10 位 ， 这 就 导致 扩展 之 前 的 git describe 输 出 完全 失效 了 。 
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5.3.8 准备 发 布 
现在 可 以 发 布 一 个 新 的 版 本 了 。 首 先 要 将 代码 的 压缩 包 归 档 ， 方 便 那 些 可 怜 的 还 没有 使 用 Git 的 人 们 。 可 以 


FA t H 
FHgit archive: 














































































































=> 
HE 
X 


$ git archive master --prefix-'project/' | gzip > ^git describe master .tar.gz 
$ 1s) * tan ez 
v1.6.2-rcl-20-g8c5b85c.tar.gz 



































这 个 压缩 包 解压 出 来 的 是 一 个 文件 夹 ， 里 面 是 你 项 目的 最 新 代码 快照 。 你 也 可 以 用 类 似 的 方法 建立 一 个 zip 
压缩 包 ， 在 git archive 加 上 --format=zip 选 项 : 
























































$ git archive master --prefix-'project/' --format=zip > ‘git describe master^.zip 











现在 你 有 了 一 个 tar .gz 压缩 包 和 一 个 zip 压 缩 包 ， 可 以 把 他 们 上 传 到 你 网 站 上 或 者 用 e-mail 发 给 别人 。 
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Scott Chacon Pro Git 5.4 节 小 结 


5.3.9 制作 简报 


是 时 候 通 知 邮件 列表 里 的 朋友 们 来 检验 你 的 成 果 了 。 使 用 git shortlog 命 令 可 以 方便 快捷 的 制作 一 份 修改 日 志 
(changelog) ， 告 诉 大 家 上 次 发 布 之 后 又 增加 了 哪些 特性 和 修复 了 哪些 bug。 实 际 上 这 个 命令 能 够 统计 给 定 
范围 内 的 所 有 提交 ;假如 你 上 一 次 发 布 的 版 本 是 v1.0.1， 下 面 的 命令 将 给 出 自从 上 次 发 布 之 后 的 所 有 提交 的 简 
fr; 
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$ git shortlog --no-merges master --not vl.0.1 
Chris Wanstrath (8): 
Add support for annotated tags to Grit::Tag 
Add packed-refs annotated tag support. 
Add Grit: :Commit#to_patch 
Update version and History.txt 
Remove stray ^puts^ 


Make ls tree ignore nils 


Tom Preston-Werner (4): 
fix dates in history 
dynamic version method 
Version bump to 1.0.2 


Regenerated gemspec for version 1.0.2 











这 就 是 自从 v1.0.1 版 本 以 来 的 所 有 提交 的 简介 ， 内 容 按照 作者 分 组 ， 以 便 你 能 快速 的 发 e-mail 给 他 们 。 











5.4 小结 






















































































尔 学 会 了 如 何 使 用 Git 为 项 目 做 贡献 ， 也 学 会 了 如 何 使 用 Git 维 护 你 的 项 目 。 茶 喜 ! 你 已 经 成 为 一 名 高 效 的 
发 者 。 在 下 一 章 你 将 学 到 更 强大 的 工具 来 处 理 更 加 复杂 的 问题 ， 之 后 你 会 变 成 一 位 Git 大 响 
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第 6 章 


Git 工具 























现在 ， 你 已 经 学 习 了 管理 或 者 维护 Git 仓库 ， 实 现代 码 控 制 所 需 的 大 多 数 日 常 命令 和 工作 流程 。 你 已 经 完 
成 了 跟踪 和 提 AL 发 挥 了 和 暂 存 区 和 轻 量 级 的 特性 分 文 及 合并 的 威力 。 

接 下 来 你 将 领略 到 一 些 Git 可 以 实现 的 非常 强大 的 功能 ， 这 些 功能 你 可 能 并 不 会 在 日 常 操作 中 使 用 ， 但 在 
某 些 时 候 你 也 许 会 需要 。 























































































































































































































6.1 修订 版 本 (Revision) 选择 



























































Git 允许 你 通过 几 种 方法 来 指明 特定 的 或 者 一 定 范围 内 的 提交 。 了 解 它们 并 不 是 必需 的 ， 但 是 了 解 一 下 总 没 
坏处 。 


























6.1.1 单个 修订 版 本 


显然 你 可 以 使 用 给 出 的 SHA-1 值 来 指明 一 次 提交 ， 不 过 也 有 更 加 人 性 化 的 方法 来 做 同样 的 事 。 本 节 概述 了 
指明 单个 提交 的 诸多 方法 。 























































































































6.1.2 简短 的 SHA 





















































Git 很 聪明 ， 它 能 够 通过 你 提供 的 前 几 个 字符 来 识别 你 想 要 的 那 次 提交 ， 只 要 你 提供 的 那 部 分 SHA-1 不 短 
于 四 个 字符 ， 没有 牙 义 一 一 也 就 是 说 ， 当 前 仓库 中 只 有 一 个 对 象 以 这 段 SHA-1 开头 。 
出 如 ， 想 要 查看 一 次 指定 的 提交 ， 假 设 你 运行 git log 命令 并 找到 你 增加 了 功能 的 那 次 提交 : 



























































































































































$ git log 
commit 734713bc047d87bf7eac9674765ae793478c50d3 
Author: Scott Chacon <schacon@gmail.com> 


Date: Fri Jan 2 18:32:33 2009 -0800 

fixed refs handling, added gc auto, updated tests 
commit d921970aadf03b3cf0e7lbecdaab3147ba7lcdef 
Merge: 1c002dd... 35cfb2b... 
Author: Scott Chacon <schacon@gmail.com> 


Date: Thu Dec 11 15:08:43 2008 -0800 


Merge commit 'phedders/rdocs' 
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commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b 


Author: Scott Chacon <schacon@gmail.com> 


Date: Thu Dec 11 14:58:32 2008 -0800 


added some blame and merge stuff 


假设 是 


$ git show 


$ git show 1 


$ git show 1 

















c002dd4b536e7479f 
c002d 








NI 


1e002dd.... ° 如果 你 想 git show 这 次 提交 ， 下 面 的 命令 是 等 价 的 (假设 简短 的 版 本 没有 歧义 ) : 





























lc002dd4b536e7479fe34593e72e6c6c1819e53b 



































Git 可 以 为 你 的 SHA-1 值 生成 出 简短 且 唯 一 的 缩写 。 如 果 你 传递 --abbrev-commit 给 sit log 命令 ,输出 结 






















































































符 数 ; 














git log --abbrev-commit --pretty-oneline 


ca82a6d changed the verison number 


085bb3b removed unnecessary test code 


allbefO first commit 























“里 就 会 使 用 简短 且 唯 一 的 值 ， 它 默认 使 用 七 个 字符 来 表示 ， 不 过 必要 时 为 了 避免 SHA-1 的 歧义 ,会 增加 字 





通常 在 一 个 项 目 中 ， 使 用 八 到 十 个 字符 来 避免 SHA-1 上 牙 义 已 经 足够 了 。 最 大 的 Git 项 目 之 一 ，Linux 内 
























































































































































12 个 字符 来 保持 唯一 性 。 






























































可 能 会 担心 一 个 问题 ， 在 随机 的 偶然 情况 下 ， 在 他 们 的 仓库 里 会 出 现 两 个 具有 相同 SHA-1 值 的 对 





















































真 的 向 仓库 里 提交 了 一 个 跟 之 前 的 茶 个 对 象 具 有 相同 SHA-1 值 的 对 象 ，Git 将 会 发 现 之 前 的 那个 对 







































































已 经 被 写 入 了 “。 如 果 什 么 时 候 你 想 再 次 检 出 那个 对 象 时 ， 你 会 总 是 得 






















































































的 概率 是 多 么 微小 。SHA-1 摘要 长 度 是 20 字 节 ， 也 就 是 160 位 。 






































一 了 


























是 1.2x1024， 也 就 是 一 亿 亿 亿 ， 那 是 地 球 上 沙 粒 总 数 的 1200 倍 。 
说 一 下 怎样 才能 产生 一 次 SHA-1 冲突 。 如 果 地 球 上 65 亿 的 人 类 都 在 编程 ， 每 人 每 秒 都 在 产生 等 





需要 290 个 随机 哈 希 的 对 象 〈 计 算 冲 突 机 率 的 公式 是 p = MOD x 






















































































价 于 整个 Linux 内 核 历史 (一 百 万 个 Git 对 象 ) 的 代码 ， 并 将 之 提交 到 一 个 巨大 的 Git 仓库 里 面 ， 那 将 花 


核 ， 目 前 也 只 需要 最 长 40 个 字符 中 的 
6.1.3 关于 SHA-1 的 简短 说 明 
waka 

象 。 那 会 怎么 样 呢 ? 

如 果 你 
象 已 经 存在 在 Git 数据 库 中 ， 并 认为 
到 先前 的 那个 对 象 的 数据 。 

不 过 ， 你 应 该 了 解 到 ， 这 种 情况 发 生 
为 了 保证 有 50% 的 概率 出 现 一 次 冲突 
gie) o 980 

现在 举例 
费 5 年 的 时 间 




























































































才 会 产生 足够 的 对 象 ， 使 其 拥有 50% 的 概率 产生 一 次 SHA-1 对 象 冲 突 。 这 要 比 你 编程 团队 的 









































成 员 同 一 个 晚上 在 互 不 相干 的 意外 中 被 狼 袭 击 并 杀 死 的 机 率 还 要 小 。 


6.1.4 











分 支 引用 

















指明 一 次 提交 的 最 直接 的 方法 要 求 有 
者 SHA-1 值 的 Git 命令 中 使 用 该 分 支 











































































































个 指向 它 的 分 支 引用 。 这 样 ， 你 就 可 以 在 任何 需要 一 个 提交 对 象 或 
名 称 了。 如 果 你 想 要 显示 一 个 分 支 的 最 后 一 次 提交 的 对 象 ， 例 如 假设 












































topic! IX AI] cag2a6d， 那 么 下 面 的 命令 是 等 价 的 : 
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T 


$ git show ca82a6dff8l7ec66f44342007202690a93763949 
$ git show topicl 


























如 果 你 想 知道 某 个 分 文 指向 哪个 特定 的 SHA， 或 者 想 看 任何 一 个 例子 中 被 简写 的 SHA-1， 你 可 以 使 用 一 个 叫 
WE rev-parse 的 Git 探测 工具 。 在 第 9 章 你 可 以 看 到 关于 探测 工具 的 更 多 信息 ; 简单 来 说 ，rev-parse 是 为 了 底 
层 操 作 而 不 是 日 常 操作 设计 的 。 不 过 ， 有 时 你 想 看 Git 现在 到 底 处 于 什么 状态 时 ， 它 可 能 会 很 有 用 。 这 里 你 
可 以 对 你 的 分 文 运 执行 rev-parse ° 


















































































































































$ git rev-parse topicl 


ca82a6dff817ec66f44342007202690293763949 


6.1.5 引用 日 志 里 的 简称 


在 你 工作 的 同时 ，Git 在 后 台 的 工作 之 一 就 是 保存 
引用 的 日 志 。 
你 可 以 使 用 git reflog 来 查看 引用 












































SE 
«ni 
E 














份 记录 最 近 几 个 月 你 的 HEAD 和 分 支 













































































$ git reflog 

734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated 
d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive. 
1c002dd... HEAD@{2}: commit: added some blame and merge stuff 

1c36188... HEAD@{3}: rebase -i (squash): updating HEAD 

95df984... HEAD@{4}: commit: £ This is a combination of two commits. 
1c36188... HEAD@{5}: rebase -i (squash): updating HEAD 

7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD 




































































每 次 你 的 分 支 顶端 因为 某 些 原因 被 修改 时 ，Git 就 会 为 你 将 信息 保存 在 这 个 临时 历史 记录 里 面 。 你 也 可 以 使 
这 份 数据 来 指明 更 早 的 分 支 。 如 果 你 想 查 看 仓库 中 HEAD 在 五 次 前 的 值 ， 你 可 以 使 用 引用 日 志 的 输出 中 的 
en 引用 : 














































































































































































































$ git show HEAD@{5} 








让 



































你 也 可 以 使 用 这 个 语法 来 了 
入 











定时 间 前 分 支 指向 哪里 。 例 如 ， 想 看 你 的 master 分 文 昨 天 在 哪 ， 你 可 以 输 


























$ git show master@{yesterday} 



























































它 就 会 显示 昨天 分 支 的 顶端 在 哪 。 这 项 技术 只 对 还 在 你 引用 日 志 里 的 数据 有 用 ， 所 以 不 能 用 来 查看 比 几 个 月 
前 还 早 的 提交 。 


想 要 看 类 似 于 sit los 输出 格式 的 引用 日 志 信息 ， 你 可 以 运行 sit log -g: 
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$ git log -g master 

commit 734713bc047d87bf7eac9674765ae793478c50d3 

Reflog: master@{0} (Scott Chacon <schacon@gmail.com>) 

Reflog message: commit: fixed refs handling, added gc auto, updated 
Author: Scott Chacon <schacon@gmail.com> 


Date: Fri Jan 2 18:32:33 2009 -0800 


fixed refs handling, added gc auto, updated tests 


commit d921970aadf03b3cf0e71becdaab3147ba7 1cdef 

Reflog: master@{1} (Scott Chacon <schacon@gmail.com>) 

Reflog message: merge phedders/rdocs: Merge made by recursive. 
Author: Scott Chacon <schacon@gmail.com> 


Date: Thu Dec 11 15:08:43 2008 -0800 


Merge commit 'phedders/rdocs' 





































































































需要 注意 的 是 ， 日 志 引 用 信息 只 存在 于 本 地 一 一 这 是 一 个 你 在 仓库 里 做 过 什么 的 日 志 。 其 他 人 的 仓库 拷贝 里 



























































































































































的 引用 和 你 的 相同 ， 而 你 新 克隆 一 个 仓库 的 时 候 ， 引 用 日 志 是 空 的 ， 因 为 你 在 仓库 里 还 没有 操作 。 只 有 你 克隆 
了 一 个 项 目 至 少 J^ J, git show HEAD@2.months.ago A 2t FB 如 你 是 五 分 前 克隆 的 仓库 ， 将 不 会 有 结 J 






















































































返回 。 


6.1.6 祖先 引用 











































































































E: 
e 
} 














另 一 种 指明 某 次 提交 的 常用 方法 是 通过 它 的 祖先 。 如 果 你 在 引用 最 后 加 上 一 个 “，Git 将 其 理解 为 此 
的 父 提交 。 假设 你 的 工程 历史 是 这 样 的 : 














$ git log --pretty=format: '%h %s' --graph 

* 734713b fixed refs handling, added gc auto, updated tests 
m d921970 Merge commit 'phedders/rdocs' 

IN 

| * 35cfb2b Some rdoc changes 

* | 1c002dd added some blame and merge stuff 

|/ 

* 1c36188 ignore *.gem 

* 9b29157 add open3 detach to gemspec file list 


















































T 





那么 ， 想 看 上 一 次 提交 ， 你 可 以 使 用 wea, AE “HEAD 的 父 提交 ”: 





$ git show HEAD^ 

commit d921970aadfO3b3cfOe7lbecdaab314T7ba7lcdef 
Merge: 1c002dd... 35cfb2b... 

Author: Scott Chacon <schacon@gmail.com> 


Date: Thu Dec 11 15:08:43 2008 -0800 


Merge commit 'phedders/rdocs' 
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Scott Chacon Pro Git 6.15 修订 版 本 (Revision) 选择 
你 也 可 以 在 Be yl d92197072 意思 是 “d921970 的 第 二 父 提交 ”。 这 种 语法 只 在 合 
提交 时 有 用 ， 因 为 合并 提交 可 能 有 多 个 父 提交 。 第 一 父 提交 是 你 合并 时 所 在 分 支 ， 而 第 二 父 提交 是 你 所 合并 的 

4) X: 
$ git show d921970^ 
commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b 
Author: Scott Chacon <schacon@gmail.com> 
Date: Thu Dec 11 14:58:32 2008 -0800 

added some blame and merge stuff 
$ git show d921970°2 
commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548 
Author: Paul Hedderly <paul+gitomjr .org> 
Date: Wed Dec 10 22:22:03 2008 +0000 

Some rdoc changes 

另外 一 个 指明 祖先 提交 的 方法 是 ~。 这 也 是 指向 第 一 父 提 交 ， 所 以 mea 和 HEAD” 是 等 价 的 。 当 你 指定 数字 

的 时 候 就 明显 不 一 样 了 。HEAp-2 是 指 “ 第 一 父 提交 的 第 一 父 提交 ”， 也 就 是 “祖父 提交 ”一 一 它 会 根据 你 指定 
的 次 数 检索 第 一 父 提交 。 例 如 ， 在 上 面 列 出 的 历史 记录 里 面 ，HEAD™3 会 是 
$ git show HEAD^3 
commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d 
Author: Tom Preston-Werner <tom@mo,jombo. com> 
Date: Fri Nov 7 13:47:59 2008 -0500 

ignore *.gem 

也 可 以 写成 HEAD…， 同 样 是 第 一 父 提 交 的 第 一 父 提 交 的 第 一 父 提交 


$ git show HEAD 
commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d 
Author: Tom Preston-Werner <tom@mo,jjombo.com> 
Date: Fri Nov 7 13:47:59 2008 -0500 


* 


ignore *.gem 








你 也 可 以 混合 使 用 这 些 语法 一 一 你 可 以 通 












































过 HEAD-3`2 指明 先前 引用 

























































































交 ) 。 
6.1.7 提交 范围 
现在 你 已 经 可 以 指明 单 次 的 提交 ， 让 我 们 来 看 看 怎 村 
如 果 你 有 很 多 分 文 ， 你 可 以 指明 范围 来 圈定 一 些 折 
到 主 分 支 的 ?” 








羊 指明 一 定 郊 日 
问题 的 答案 ， 


的 第 二 父 提 


交 (假设 它 








m 
ar 





的 提交 ° 














你 管理 








这 在 





分 支 的 时 候 尤 显 


x 





El 个 全 
口 





























比如 : 


I» 




















这 个 分 支 上 我 有 哪些 了 


pus 
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6x Git 











LA 


双 点 


T XH 





最 常用 的 指明 范围 的 方法 是 双 点 的 i 
获得 的 提交 。 例 如 ， 假 设 你 有 类 似 于 图 



































o 




















"iA 














这 种 语法 主要 是 让 Git 
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区 分 出 可 从 一 个 分 文 











6.1 的 提交 历史 。 


-© ©- 
-© 




























































































获得 而 不 能 从 master 分 支 中 获得 的 提交 ” 






































图 6.1: 范围 选择 的 提交 历史 实例 
你 想 要 查看 你 的 试验 分 支 上 哪些 没有 被 提交 到 主 分 支 ， 那 么 你 就 可 
这 些 提交 的 日 志 这 句 话 的 意思 是 “所 有 可 从 experiment 分 文 
为 了 使 例子 简单 明了 ， 我 使 用 了 图 标 中 提交 对 象 的 字母 来 代替 真实 




















$ git log master..experiemnt 


D 
C 


r1 


Fl 

















一 方面 ， 如 果 你 想 看 相反 的 一 一 所 有 在 master 而 不 在 experiment 中 的 分 文 一 一 你 可 以 交换 分 支 的 名 


字 ° experiment..master 显示 所 有 可 在 master 获得 而 在 experiment F 














$ git log experiment. .master 


F 
E 





这 在 你 想 保 持 experiment 分 文 最 新 和 预览 你 将 
看 你 将 把 什么 推送 到 远程 : 











$ git log origin/master. .HEAD 





条 命令 














显示 任何 在 















































果 一 一 Git 使 用 HE 








宗 origin/master , 被 git 
的 一 边 来 让 Git 来 假定 它 是 


PCAN TEER 


你 当前 分 支 上 而 不 在 





















































D» 














不 能 的 提交 : 








的 提交 的 时 候 特 别 有 用 。 这 个 语法 的 另 一 种 常见 用 i 

















远程 origin 上 的 提交 。 如 果 你 运行 sit push Jf 














AD 2j 















































多 点 

双 点 语法 就 像 速记 一 样 有 用 ; 但 是 你 也 许 
含 在 某 些 分 文中 的 一 个 ， 但 是 不 在 你 当前 的 
被 包含 其 中 的 分 支 。 因 此 下 面 三 个 命令 是 等 












































130 


log origin/master..HEAD JH 


























H 


时 而 不 能 从 另 一 














= 


aK 




















以 使 用 master. .experiment 来 让 Git MEZ ZJN 











o 





志 的 输出 ， 所 以 会 显示 : 





























途 是 查 
且 的 你 的 当前 分 支 正 








的 提交 就 是 将 被 传输 到 服务 器 上 的 提交 。 你 也 可 以 留 
HEAD 。 例如 , 输入 git log origin/master.. 将 得 





到 




















和 上 面 的 例子 一 样 的 





























会 想 针 对 两 个 以 上 的 分 支 来 指明 修订 版 本 ， 比 如 查看 哪些 提交 被 包 
分 文 上 。Git 人 允许 你 在 引用 前 使 用 "字符 或 者 --not 指 明 你 不 希望 提交 








同 的 : 
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$ git log refA..refB 
$ git log ^refA refB 
$ git log refB --not refA 





















































这 样 很 好 ， 因 为 它 允 许 你 在 查询 中 指定 多 于 两 个 的 引用 ， 而 这 是 双 点 语法 所 做 不 到 的 。 例 如 ， 如 果 你 想 查找 
所 有 从 refa 或 refB 包 含 的 但 是 不 被 refc 包 含 的 提交 ， 你 可 以 输入 下 面 中 的 一 个 











































































































$ git log refA refB ^refC 
$ git log refA refB --not refC 








S 
ict 






































这 建立 了 一 个 非常 强大 的 修订 版 本 查询 系统 ， 应 该 可 以 帮助 你 解决 包含 了 什么 这 个 问题 。 












































最 后 一 种 主要 的 范围 选择 语法 是 三 点 语法 ， 这 个 可 以 指定 被 两 个 引用 中 的 一 个 包含 但 又 不 被 两 者 同时 包含 的 
分 文 。 回 过 头 来 看 一 下 图 6-1 里 所 列 的 提交 历史 的 例子 。 如 果 你 想 查 看 master 或 者 experiment 中 包含 的 但 不 是 两 
者 共有 的 引用 ， 你 可 以 运行 































































































































































































$ git log master...experiment 


F 


E 
D 
© 
















































































































































































这 个 再 次 给 出 你 普通 的 10g 输 出 但 是 只 显示 那 四 次 提交 的 信息 ， 按 照 传统 的 提交 日 期 排列 。 
这 种 情形 下 ，1log 命 令 的 一 个 常用 参数 是 --left-right， 它 会 显示 每 个 提交 到 底 处 于 哪 一 侧 的 分 文 。 这 使 得 数据 
更 加 有 用 。 











$ git log --left-right master...experiment 
<F 
SEE 
> D 
gx 





有 了 以 上 工具 ， 让 Git 知 道 你 要 察看 哪些 提交 就 容易 得 多 了 。 



































6.2 交互 式 暂 存 


Git 提 供 了 很 多 脚本 来 辅助 某 些 命令 行 任务 。 这 里 ， 你 将 看 到 一 些 交互 式 命令 ， 它 们 帮助 你 方便 地 构建 只 包 
含 特定 组 合 和 部 分 文件 的 提交 。 在 你 修改 了 一 大 批文 件 然后 决定 将 这 些 变 更 分 布 在 儿 个 各 有 侧重 的 提交 而 不 是 
单个 又 大 又 乱 的 提交 时 ， 这 些 工具 非常 有 用 。 用 这 种 方法 ， 你 可 以 确保 你 的 提交 在 逻辑 上 划分 为 相应 的 变更 
集 ， 以 便于 供 和 你 一 起 工作 的 开发 者 审阅 。 
如 果 你 运行 sit adqd 时 加 上 -i 或 者 --interactive 选 项 ，Git 就 进入 了 一 个 交互 式 的 shell 模 式 ， 显 示 一 些 类 似 于 
面 的 信息 : 
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$ git add -i 


staged unstaged path 
ile unchanged +0/-1 TODO 
De unchanged +1/-1 index.html 
as unchanged +5/-1 lib/simplegit.rb 


*** Commands *** 





























1: status 2: update 3: revert 4: add untracked 
5: patch 6: diff Ts quit 8: help 
What now» 
你 会 看 到 这 个 命令 以 一 个 完全 不 同 的 视图 显示 了 你 的 暂 存 区 主要 是 你 通过 git status 得 到 的 那些 信息 但 是 































































































稍微 简洁 但 信息 更 加 丰富 一 些 。 它 在 左 侧 列 出 了 你 暂 存 的 变更 ， 在 右 侧 列 出 了 未 被 暂 存 的 变更 。 
在 这 之 后 是 一 个 命令 区 。 这 里 你 可 以 做 很 多 事情 ， 包 括 暂 存 文件 ， 撤 回 文件 ， 和 暂 存 部 分 文件 ， 加 入 未 被 追踪 
的 文件 ， 查 看 暂 存 文件 


















































































































































v 
ss 
ài 
Mo 











6.2.1 暂 存 和 撤回 文件 


如 果 你 在 what now> 的 提示 后 输入 2 或者"， 这 个 脚本 会 提示 你 那些 文件 你 想 要 暂 存 : 



























































What now> 2 
staged unstaged path 
ike unchanged +0/-1 TODO 
De unchanged +1/-1 index.html 
we unchanged +5/-1 lib/simplegit.rb 
Update>> 




















如 果 想 暂 存 TODO 和 index.html， 你 可 以 输入 相应 的 编号 : 











Update>> 1,2 


staged unstaged path 
Si unchanged +0/-1 TODO 
nei unchanged +1/-1 index.html 
Ss unchanged +5/-1 lib/simplegit.rb 


Update>> 





















































每 个 文件 旁边 的 * 表 示 选 中 的 文件 将 被 暂 存 。 如 果 你 在 update>> 提 示 后 直接 融入 
内 容 暂 存 : 





H 




















E 












































车 ，Git 会 奉 你 把 所 有 选中 的 





Update>> 
updated 2 paths 


*** Commands *** 


1: status 2: update 3: revert 4: add untracked 
5: patch 6: diff 7: quit 8: help 
What now» 1 
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staged 
ilg +0/-1 
2 +1/-1 
Oly unchanged 


现在 你 可 以 看 到 TODO 和 index.html 文 伯 








unstaged path 
nothing TODO 
nothing index.html 
+5/-1 lib/simplegit.rb 














F 








TODO 文 件 ， 就 使 用 3 或 者 r (代表 revert， 恢 复 ) 选项 : 


*** Commands *** 


1: status D 
5: patch 6: 


What now» 3 
stage 
1: *0/-1 
De +1/-1 
3 unchanged 


Revert>> 1 





stage 

7 Jig *0/-1 
De +1/-1 
$8 unchanged 


Revert>> [enter] 


reverted one path 





























*** Commands *** 


1: status 25 
5: patch 6: 


What now> 1 
staged 
1: unchanged 
2s +11 


ole unchanged 


再 次 查看 Git 的 状态 ， 你 会 看 到 你 已 经 撤 





update 3: revert 4: add untracked 
diff 7: quit 8: help 
unstaged path 
nothing TODO 
nothing index.html 
+5/-1 lib/simplegit.rb 


unstaged path 
nothing TODO 
nothing index.html 
+5/-1 lib/simplegit.rb 











H 


FF 








T TODO 4# 














update 3: revert 4: add untracked 
diff 7: quit 8: help 
unstaged path 
+0/-1 TODO 
nothing index.html 
+5/-1 lib/simplegit.rb 












































看 你 暂 存 内 容 的 差异 ， 你 可 以 使 用 6 或 者 d (表示 diff) 















































中 的 儿 个 ， 显 示 
































*** Commands *** 





1: status 2: update 3: revert 4: add untracked 
5: patch 6: diff 7: quit 8: help 
What now> 6 
staged unstaged path 
ilg +1/-1 nothing index.html 


Review diff>> 1 


diff --git a/index.html b/index.html 
index 4d07108..4335f49 100644 


--- a/index.html 


F 被 暂 存 了 同时 simplegit.rb 文 伯 


AA 


Ea 


6.25 RENEE 


























仍然 下 








被 暂 存 。 如 果 这 时 你 想 要 撤 




















° 它 会 显示 你 暂 存 文 伯 


Ud 


让 被 暂 存 的 差异 。 这 跟 你 在 命令 行 下 指定 git diff —cacheddE à 





Bj 





相似 : 





H 














的 列表 ， 你 可 以 选择 
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+++ b/index.html 
@@ -16,7 +16,7 eo Date Finder 


<p id="out">...</p> 


-<div id="footer">contact : support@github.com</div> 


+<div id="footer">contact : email.support@github.com</div> 


<script type="text/javascript"> 
















































































通过 这 些 基本 命令 ， 你 可 以 使 用 交互 式 增加 模式 更 加 方便 地 处 到 














6.2.2 暂 存 补丁 






























































让 Git 暂 存 文件 的 茶 些 部 分 而 忽略 其 他 也 是 有 可 能 的 。 例 如 ， 你 对 si 





mplegit.rb 文 件 作 了 


Scott Chacon Pro Git 


















































只 想 暂 存 其 中 一 个 而 忽略 男 一 个 ， 在 Git 中 实现 这 一 点 非常 容易 。 在 交互 式 的 提示 符 




















ay 


patch, #hJ) 。Git 会 询问 哪些 文 付 
异 区 块 并 询问 你 是 否 希 望 暂 存 他 们 : 






































inm 








diff --git a/lib/simplegit.rb b/lib/simplegit.rb 
index dd5ecc4..57399e0 100644 

--- a/lib/simplegit.rb 

+++ b/lib/simplegit.rb 

eo -22,7 +22,7 @@ class SimpleGit 


end 


def log(treeish = 'master') 
- command("git log -n 25 Z(treeish)") 
* command("git log -n 30 Z(treeish)") 


end 


def blame(path) 
Stage this hunk [y,n,a,d,/,j,J,g,e,?]? 








此 处 你 有 很 多 选择 。 输 入 ?可 以 显示 列表 : 








Stage this hunk [y,n,a,d,/,j,J,g,e,?]? ? 

y - stage this hunk 

n - do not stage this hunk 

a - stage this and all the remaining hunks in the file 

d - do not stage this hunk nor any of the remaining hunks in the file 
g - select a hunk to go to 

/ - search for a hunk matching the given regex 

j - leave this hunk undecided, see next undecided hunk 

J - leave this hunk undecided, see next hunk 

k - leave this hunk undecided, see previous undecided hunk 
K - leave this hunk undecided, see previous hunk 

s - split the current hunk into smaller hunks 

e - manually edit the current hunk 


7 - print help 


134 








尔 希 望 部 分 暂 存 ， 然 后 对 于 被 选 














ES 





文人 


一 全 ， 他 会 逐个 














Ej 


MP 











pog ips 
， 输 入 5 或 者 p GRIS 





示 文 伯 




















Jz 
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6.35 储藏 (Stashing) 






























































































































































































































































































































































































































































































































































































































































如 果 你 想 暂 存 各 个 区 块 ， 通 常 你 会 输入 yx 或 者 a*， 但 是 暂 存 特定 文件 里 的 全 部 区 块 或 者 暂时 跳 过 对 一 个 区 块 的 
处 理 同 样 也 很 有 用 。 如 果 你 暂 存 了 文件 的 一 个 部 分 而 保留 男 外 一 个 部 分 不 被 暂 存 ， 你 的 状态 输出 看 起 来 会 是 这 
样 : 

What now> 1 
staged unstaged path 

1: unchanged *0/-1 TODO 

2: +1/-1 nothing index.html 

3: +1/-1 +4/-0 lib/simplegit.rb 

simplegit.rb 的 状态 非常 有 意思 。 它 显示 有 儿 行 被 暂 存 了 ， 有 几 行 没有 。 你 部 分 地 暂 存 了 这 个 文件 。 在 这 
时 ， 你 可 以 退出 交互 式 脚本 然后 运行 git commit 来 提交 部 分 暂 存 的 文件 。 

最 后 你 也 可 以 不 通过 交互 式 增加 的 模式 来 实现 部 分 文件 暂 存 一 一 你 可 以 在 命令 行 下 通过 git add -p 或 者 git add 
_wteh 来 启动 同样 的 脚本 。 

6.3 储藏 (Stashing ) 

经 常 有 这 样 的 事情 发 生 ， 当 你 正在 进行 项 目 中 某 一 部 分 的 工作 ， 里 面 的 东西 处 于 一 个 比较 杂乱 的 状态 ， 而 你 
想 转 到 其 他 分 支 上 进行 一 些 工 作 。 问 题 是 ， 你 不 想 提 交 进 行 了 一 半 的 工作 ， 否 则 以 后 你 无 法 回 到 这 个 工作 点 。 
解决 这 个 问题 的 办 法 就 是 git stash 命 令 。 

" “储藏 ”“ 可 以 获取 你 工作 目录 的 中 间 状 态 一 一 也 就 是 你 修改 过 的 被 追踪 的 文件 和 和 暂 存 的 变更 将 它 
保存 到 一 个 未 完结 变更 的 堆栈 中 ， 随 时 可 以 重新 应 用 。 
6.3.1 储藏 你 的 工作 

为 了 演示 这 一 功能 ， 你 可 以 进入 你 的 项 目 ， 在 一 些 文件 上 进行 工作 ， 有 可 能 还 暂 存 其 中 一 个 变更 。 如 果 你 运 
ÍT git status, S NOLENS 间 状 态 : 
$ git status 
# On branch master 
# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# 

# modified: index.html 

# 

# Changed but not updated: 

# (use "git add <file>..." to update what will be committed) 
# 

# modified: lib/simplegit.rb 

# 

现在 你 想 切 换 分 支 ， 但 是 你 还 不 想 提 交 你 正在 进行 中 的 工作 ， 所 以 你 储藏 这 些 变更 。 为 了 往 堆 栈 推送 一 个 新 
的 储藏 ， 只 要 运行 git stash: 
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$ git stash 
Saved working directory and index state \ 
"WIP on master: 049d078 added the index file" 
HEAD is now at 049d078 added the index file 
(To restore them type "git stash apply") 

















你 的 工作 目录 就 干净 了 : 











$ git status 
# On branch master 


nothing to commit (working directory clean) 












































这 时 ， 你 可 以 方便 地 切换 到 其 他 分 支 工作 ;你 的 变更 都 保存 在 栈 上 。 要 查看 现 有 的 储藏 ， 你 可 以 使 用 sit 


stash list: 












































$ git stash list 

stash@{0}: WIP on master: 049d078 added the index file 
stash@{1}: WIP on master: c264051... Revert "added file size" 
stasho{2}: WIP on master: 21d80a5... added number to log 


























在 这 个 案例 中 ， 之 前 已 经 进行 了 两 次 储藏 ， 所 以 你 可 以 访问 到 三 个 不 同 的 储藏 。 你 可 以 重新 应 用 你 刚刚 实施 
的 储藏 ， 所 采用 的 命令 就 是 之 前 在 原始 的 stash 命令 的 帮助 输出 里 提示 的 : git stash apply。 如 果 你 想 应 用 更 
早 的 储 减 ， 你 可 以 通过 名 字 指 定 它 ， 像 这 样 : git stash apply stasho2。 如 果 你 不 指明 ，Git 默认 使 用 最 近 的 储 关 


党 斌 应 J É: 




















































































































































































































$ git stash apply 
# On branch master 


# Changed but not updated: 


# (use "git add <file>..." to update what will be committed) 
# 

# modified: ^ index.html 

# modified: lib/simplegit.rb 

# 
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你 可 以 看 到 Git 重新 修改 了 你 所 储藏 的 那些 当时 尚未 提交 的 文件 。 在 这 个 案例 里 ， 你 尝试 应 用 储藏 的 工作 
孙 是 干净 的 ， 并 且 属 于 同一 分 文 ;但 是 一 个 干净 的 工作 目录 和 应 用 到 相同 的 分 支 上 并 不 是 应 用 储藏 的 必要 条 
Fe 你 可 以 在 其 中 一 个 分 支 上 保留 一 份 储藏 ， 随 后 切换 到 另外 一 个 分 支 ， 再 重新 应 用 这 些 变更 。 在 工作 目录 里 
含 已 修改 和 未 提交 的 文件 时 ， 你 也 可 以 应 用 储藏 一 一 Git 会 给 出 归并 冲突 如 果 有 任何 变更 无 法 干净 地 被 应 
对 文件 的 变更 被 重新 应 用 ， 但 是 被 暂 存 的 文件 没有 重新 被 暂 存 。 想 那样 的 话 ， 你 必须 在 运行 git stash apply 
命令 时 带 上 一 个 --index 的 选项 来 告诉 命令 重新 应 用 被 特 存 的 变更 。 如 有 果 你 是 这 么 做 的 ， 你 应 该 已 经 回 到 你 原 


来 的 位 置 : 
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Scott Chacon Pro Git 6.3 $ 储藏 (Stashing) 


$ git stash apply --index 
# On branch master 


# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 

# 

# modified: index.html 

# 

# Changed but not updated: 

# (use "git add <file>..." to update what will be committed) 
# 

# modified: lib/simplegit.rb 

# 














apply 选项 只 尝试 应 用 储藏 的 工作 一 一 储藏 的 内 容 仍然 在 栈 上 。 要 移 除 它 ， 你 可 以 运行 git stash drop， 加 上 
你 希望 移 除 的 储藏 的 名 字 : 
































$ git stash list 

stash@{0}: WIP on master: 049d078 added the index file 
stash@{1}: WIP on master: c264051... Revert "added file size" 
stashe(2): WIP on master: 21d80a5... added number to log 

$ git stash drop stasho{0} 

Dropped stasho{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43 ) 









































你 也 可 以 运行 git stash pop 来 上 
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新 应 用 储藏 ， 同 时 立刻 将 其 从 堆栈 中 移居 
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6.3.2 从 储藏 中 创建 分 支 


如 果 你 储藏 了 一 些 工 作 ， 和 暂时 不 去 理会 ， 然 后 继续 在 你 储藏 工作 的 分 支 上 工作 ， 你 在 重新 应 用 工作 时 可 能 会 
倍 到 一 些 问题 。 如 果 尝 试 应 用 的 变更 是 针对 一 个 你 那 之 后 修改 过 的 文件 ， 你 会 磁 到 一 个 归并 冲突 并 且 必 须 去 化 


解 它 。 如 果 你 想 用 更 方便 的 方法 来 重新 检验 你 储藏 的 变更 ， 你 可 以 运行 sit stash branch, SOL 
支 ， 检 出 你 储藏 工作 时 的 所 处 的 提交 ， 重 新 应 用 你 的 工作 ， 如 果 成 功 ， 将 会 丢弃 储藏 。 
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$ git stash branch testchanges 
Switched to a new branch "testchanges" 
# On branch testchanges 

# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 

# 

# modified: index.html 

# 

# Changed but not updated: 

# (use "git add <file>..." to update what will be committed) 
# 

# modified: lib/simplegit.rb 

# 


Dropped refs/stashe(0) (fOdfc4d5dc332d1cee34a634182e168c4efc3359) 














个 很 棒 的 捷径 来 恢复 储藏 的 工作 然后 在 新 的 分 文 上 继续 当时 的 工作 。 
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第 6 章 Git Scott Chacon Pro Git 











6.4 重 写 历史 


很 多 时 候 ， 在 Git 上 工作 的 时 候 ， 你 也 许 会 由 于 某 种 原因 想 要 修订 你 的 提交 历史 。Git 的 一 个 卓越 之 处 就 
是 它 允 许 你 在 最 后 可 能 的 时 刻 再 作 决 定 。 你 可 以 在 你 即将 提交 暂 存 区 时 决定 什么 文件 归 入 哪 一 次 提交 ， 你 可 以 
使 用 stash 命令 来 决定 你 暂时 搁置 的 工作 ， 你 可 以 重 写 已 经 发 生 的 提交 以 使 它们 看 起 来 是 另外 一 种 样子 。 这 
个 包括 改变 提交 的 次 序 、 改 变 说 明 或 者 修改 提交 中 包含 的 文件 ， 将 提交 归并 、 拆 分 或 者 完全 删除 一 一 这 一 切 在 
你 尚未 开始 将 你 的 工作 和 别人 共享 前 都 是 可 以 的 。 
企 这 一 节 中 ， 你 会 学 到 如 何 完成 这 些 很 有 用 的 任务 以 使 你 的 提交 历史 在 你 将 其 共享 给 别人 之 前 变 成 你 想 要 的 












































































































































































































































































































































6.4.1 改变 最 近 一 次 提交 





























攻 次 提交 也 许 是 ee. 次 提交 ， 你 经 常 想 做 两 件 基本 事情 ， 改 
变 提交 说 明 ， 或 者 改变 你 刚刚 通过 增加 ， 改 变 ， 删 除 而 记录 的 快照 。 
如 果 你 只 楚 i Ame. 
















































































$ git commit --amend 










































































这 会 把 你 带 入 文本 编辑 器 ， 里 面包 含 了 你 最 近 一 次 提交 说 明 ， 供 你 修改 。 当 你 保存 并 退出 编辑 器 ， 这 个 编辑 
会 写 入 一 个 新 的 提交 ， 里 面包 含 了 那个 说 明 ， 并 且 让 它 成 为 你 的 新 的 最 近 一 次 提交 。 
如 果 你 完成 提交 后 又 想 修改 被 提交 的 快照 ， 增 加 或 者 修改 其 中 的 文件 ， 可 能 因为 你 最 初 提交 时 ， 忘 了 添加 一 
个 新 建 的 文件 ， 这 个 过 程 基本 上 一 样 。 你 通过 修改 文件 然后 对 其 运行 sit au 或 对 一 个 已 被 记录 的 文件 运行 sit 
rm， 随 后 的 git commit --amend 会 获取 你 当前 的 暂 存 区 并 将 它 作为 新 提交 对 应 的 快照 。 

使 用 这 项 技术 的 时 候 你 必须 小 心 ， 因 为 修正 会 改变 提交 的 SHA-1 值 。 这 个 很 像 是 一 次 非常 小 的 rebase 一 一 不 
要 在 你 最 近 一 次 提交 被 推送 后 还 去 修正 它 。 
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6.4.2 修改 多 个 提交 说 明 






















































































要 修改 历史 中 更 早 的 提交 ， 你 必须 采用 更 复杂 的 工具 。Git 没 有 一 个 修改 历史 的 工具 ， 但 是 你 可 以 使 用 
rebase 工 具 来 衍 合 一 系列 的 提交 到 它们 原来 所 在 的 HEAD 上 而 不 是 移 到 新 的 上 。 依 靠 这 个 交互 式 的 rebase 工 
具 ， 你 就 可 以 停留 在 每 一 次 提交 后 ， 如 果 你 想 修改 或 改变 说 明 、 增 加 文件 或 任何 其 他 事情 。 你 可 以 通过 给 git 
rebase 增 加 -i 选 项 来 以 交互 方式 地 运行 rebase。 你 必须 通过 告诉 命令 衍 合 到 哪 次 提交 ， 来 指明 你 需要 重 写 的 提 
CH [EL WARE © 

例如 ， 你 想 修改 最 近 三 次 的 提交 说 明 ， 或 者 其 中 任意 一 次 ， 你 必须 给 git rebase -i 提供 一 个 参数 ， 指 明 你 想 
要 修改 的 提交 的 父 提交 ， Blau oso 。 可 能 记 住 -3 更 加 容易 ， 因 为 你 想 修改 最 近 三 次 提交 ; 但 是 请 记 
住 你 事实 上 所 指 的 是 四 次 提交 之 前 ， 即 你 想 修改 的 提交 的 父 提交 © 
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$ git rebase -i HEAD^3 




















HAREE — “MiB fi Eas. HEADYE, ELLE E REBRE, JOE MGE DIL ° RSEN 
盖 你 已 经 推送 到 中 心服 务 器 的 提交 一 一 这 么 做 会 使 其 他 开发 者 产生 混乱 ， 因 为 你 提供 了 同样 变更 的 不 同 版 本 。 
运行 这 个 命令 会 为 你 的 文本 编辑 器 提供 一 个 提交 列表 ， 看 起 来 像 下 面 这 样 
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Scott Chacon Pro Git 


pick f7f3f6d changed my name a bit 
pick 310154e updated README formatting and added blame 
pick a5f4a0d added cat-file 


# Rebase 710f0f8..a5f4a0d onto 710f0f8 
# 

# Commands: 

# p, pick = use commit 

# e, edit = use commit, but stop for amending 

# s, squash = use commit, but meld into previous commit 
# 

# If you remove a line here THAT COMMIT WILL BE LOST. 


# However, if you remove everything, the rebase will be aborted. 





























mith 




















很 重要 的 一 点 是 你 得 注意 这 些 提交 的 顺序 与 你 通常 通过 1og 命 令 


下 面 这 样 的 结果 : 















































$ git log --pretty=format:"%h %s" HEAD^3..HEAD 
a5f4a0d added cat-file 

310154e updated README formatting and added blame 
f'f3f6d changed my name a bit 







































































请 注意 这 里 的 倒序 。 交 互 式 的 rebase 给 了 你 一 个 即将 运行 的 脚本 。 它 会 从 你 在 命令 





到 的 是 相反 的 。 如 时 
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(HEAD™3) 然后 目 上 至 下 重播 每 次 提交 里 引入 的 变更 。 它 将 最 早 的 列 在 项 上 而 不 是 最 近 的 ， 






































































































































你 运行 1og， 你 会 看 到 





信行 上 指明 的 提交 开始 








大 





为 这 是 第 一 个 需要 








员 修 改 的 每 一 次 提交 前 面 







































































重播 的 。 
你 需要 修改 这 个 脚本 来 让 它 停留 在 你 想 修改 的 变更 上 。 要 做 到 这 一 点 ， 你 只 要 将 你 楚 
的 pick 改 为 edit。 例 如 ， 只 想 修 改 第 三 次 提交 说 明 的 话 ， ae 修改 文件 : 
edit f7f3f6d changed my name a bit 
pick 310154e updated README formatting and added blame 
pick a5f4a0d added cat-file 
当 你 保存 并 退出 编辑 器 ，Git 会 倒 回 至 列表 中 的 最 后 一 次 提交 ， 然 后 把 你 送 到 命令 行 

































































$ git rebase -i HEAD^3 
Stopped at 7482e0d... updated the gemspec to hopefully work better 
You can amend the commit now, with 

git commit --amend 


Once you’ re satisfied with your changes, run 


git rebase --continue 














中 ， 同 时 显示 以 下 信 
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第 6 章 Git 工具 Scott Chacon Pro Git 




















这 些 指示 很 明确 地 告诉 了 你 该 干什么 。 输 入 

















$ git commit --amend 





修改 提交 说 明 ， 退 出 编辑 器 。 然 后 ， 运 行 





























$ git rebase --continue 
























































这 个 命令 会 自动 应 用 其 他 两 次 提交 ， 你 就 完成 任务 了 。 如 果 你 将 更 多 行 的 pick BON edit ， 你 就 能 对 你 想 
修改 的 提交 重复 这 些 步 又 = Git 每 次 都 会 停 下 ， 让 你 修正 提交 ， 完 成 后 继续 运行 。 









































6.4.3 EPRI 
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你 也 可 以 使 用 交互 式 的 衍 合 来 彻底 重 排 或 删除 提交 。 如 果 你 想 删除 "added cat-file" XA 
他 两 次 提交 引入 的 顺序 ， 你 将 rebase 脚 本 从 这 个 























修改 其 
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pick f7f3f6d changed my name a bit 
pick 310154e updated README formatting and added blame 
pick a5f4a0d added cat-file 


改 为 这 个 


pick 310154e updated README formatting and added blame 
pick f7f3f6d changed my name a bit 
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当 你 保存 并 退出 编辑 器 ，Git 将 分 支 倒 回 至 这 些 提交 的 父 提交 ， 应 用 310154e， 然 后 f7f3f6d， 接 着 停止 。 你 有 
效 地 修改 了 这 些 提交 的 顺序 并 且 彻 底 删 除了 “added cat-file” 这 次 提交 。 










































































6.4.4 压制 (Squashing) 提 交 






























































交互 式 的 衍 合 工具 还 可 以 将 一 系列 提交 压制 为 单一 提交 。 脚 本 在 rebase 的 信息 里 放 了 一 些 有 用 的 指示 : 





























# 

# Commands: 

# p, pick = use commit 
# e, edit = use commit, but stop for amending 

# s, squash = use commit, but meld into previous commit 
# 

# If you remove a line here THAT COMMIT WILL BE LOST. 


# However, if you remove everything, the rebase will be aborted. 


# 
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Scott Chacon Pro Git 6.4 节 
























































如 果 不 用 “pick ”或 者 “edit”， 而 是 指定 “squash”，Git 会 同时 应 用 那个 变更 和 它 之 前 的 变更 并 将 提交 
说 明 归 并 。 因 此 ， 如 果 你 想 将 这 三 个 提交 合并 为 单一 提交 ， 你 可 以 将 脚本 修改 成 这 样 : 
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pick f7f3f6d changed my name a bit 
squash 310154e updated README formatting and added blame 
squash a5f4a0d added cat-file 






























































当 你 保存 并 退出 编辑 器 ，Git 会 应 用 





Hp 
nk 
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次 变更 然后 将 你 送 回 编辑 器 来 归并 三 次 提交 说 明 o 



































# This is a combination of 3 commits. 

# The first commit's message is: 

changed my name a bit 

# This is the 2nd commit message: 

updated README formatting and added blame 


# This is the 3rd commit message: 


added cat-file 












































当 你 保存 之 后 ， 你 就 拥有 了 一 个 包含 前 三 次 提交 的 全 部 变更 的 单一 提交 。 














6.4.5 拆 分 提交 


拆 分 提交 就 是 撤销 一 次 提交 ， 然 后 多 次 部 分 地 暂 存 或 提交 直到 结束 。 例 如 ， 假 设 你 想 将 三 次 提交 中 的 中 
间 一 次 拆 分 。 将 “updated README formatting and added blame” 拆 分 成 两 次 提交 : 第 一 次 为 “updated 
README formatting”， 第 二 次 为 “added blame" 。 你 可 以 在 rebase -i 脚 本 中 修改 你 想 拆 分 的 提交 前 的 指令 
为 “edit” 




































































pick f7f3f6d changed my name a bit 
edit 310154e updated README formatting and added blame 
pick a5f4a0d added cat-file 


















































然后 ， 这 个 脚本 就 将 你 带 入 命令 行 ， 你 重 置 那 次 提交 ， 提 取 被 重 置 的 变更 ， 从 中 创建 多 次 提交 。 当 你 保 
存 并 退出 编辑 器 ，Git 倒 回 到 列表 中 第 一 次 提交 的 父 提交 ， 应 用 第 一 次 提交 (errre) ， 应 用 第 二 次 提交 
(310154e) ， 然 后 将 你 带 到 控制 台 。 那 里 你 可 以 用 git reset HEAD 对 那 次 提交 进行 一 次 混合 的 重 置 ， 这 将 撤销 那 
次 提交 并 且 将 修改 的 文件 撤回 。 此 时 你 可 以 暂 存 并 提交 文件 ， 直 到 你 拥有 多 次 提交 ， 结 束 后 ， 运 行 git rebase 


--continue ° 
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git reset HEAD^ 

git add README 

git commit -m 'updated README formatting' 
add lib/simplegit.rb 


git commit -m 'added blame' 


Ce de Ge cB US We 
09 
E 
ct 


git rebase --continue 
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第 6 章 cit 工具 
Git 在 脚本 中 应 用 了 最 后 一 次 提交 (a5f4a0d) ， 你 的 历史 看 起 来 就 像 这 样 了 : 
$ git log -4 --pretty=format:"%h Xs" 
1c002dd added cat-file 
9b29157 added blame 
35cfb2b updated README formatting 
f3cc40e changed my name a bit 
再 次 提醒 ， 这 会 修改 你 列表 中 的 提交 的 SHA 值 ， 所 以 请 确保 这 个 列表 里 不 包含 你 已 
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Scott Chacon Pro Git 



































经 推送 到 共享 仓库 的 提 

































































































































































































































































































































































































































































































































































































































































6.4.6 核弹 级 选项 : filter-branch 

如 果 你 想 用 脚本 的 方式 修改 大 量 的 提交 ， 还 有 一 个 重 写 历 史 的 选项 可 以 用 一 一 例如 ， 全 局 性 地 修改 电子 邮件 
a 中 删除 。 这 个 命令 是 filter-branch， 这 个 会 大 面积 地 修改 你 的 历史 ， 所 以 你 很 
有 可 能 不 该 去 ， 除 非 你 的 项 目 尚未 公开 ， 没 有 其 他 人 在 你 准备 修改 的 提交 的 基础 上 工作 。 尽 管 如 此 ， 这 个 
可 以 非常 有 用 。 dices 一 些 常见 用 法 ， 借 此 对 它 的 能 力 有 所 认识 。 
从 所 有 提交 中 删除 一 个 文件 

这 个 经 常 发 生 。 有 些 人 不 经 思考 使 用 sit ada .， 意 外 地 提交 了 一 个 巨大 的 二 进 制 文件 ， 你 想 将 它 从 所 有 地 
es 。 也 许 你 不 小 心 提交 了 一 个 包含 密码 的 文件 ， 而 你 想 让 你 的 项 目 开 源 。filter-branch 大 概 会 是 你 用 来 清 

个 历史 的 工具 。 要 从 整个 历史 中 删除 一 个 名 叫 password.txt 的 文件 ， 你 可 以 在 filter-branch 上 使 用 --tree- 

$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD 
Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21) 
Ref 'refs/heads/master' was rewritten 

--tree-filter 选 项 会 在 每 次 检 出 项 目 时 先 执行 指定 的 命令 然后 重新 提交 结果 。 在 这 个 例子 尔 会 在 所 有 快 
照 中 删除 一 个 名 叫 password.txt 的 文件 ， 无 论 它 是 否 存 在 。 如 果 你 想 删 除 所 有 不 小 心 提交 上 去 的 编辑 器 备份 
文件 ， 你 可 以 运行 类 化 git filter-branch --tree-filter 'rm -f *^' HEAD Af o 

你 可 以 观察 到 Git 重 写 目录 树 并 且 提 交 ， 然 后 将 分 支 指 针 移 到 末尾 。 一 个 比较 好 的 办 法 是 在 一 个 测试 分 
支 上 做 这 些 然后 在 你 确定 产物 真 的 是 你 所 要 的 之 后 ， 再 hard-reset 你 的 主 分 支 。 要 在 你 所 有 的 分 文 上 运 

































































行 filter-branch 的 话 ， 你 可 以 传递 一 个 --all 给 命令 o 
将 一 个 子 目录 设置 为 新 的 根 目 录 

假设 你 完成 了 从 另外 一 个 代码 控制 系统 的 导入 工作 ， 
如 果 你 想 让 trunk 子 目录 成 为 每 一 次 提交 的 新 的 项 目 根 




























































































$ git filter-branch --subdirectory-filter trunk HEAD 
Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12) 


Ref 'refs/heads/master' was rewritten 








现在 你 的 项 





根 


录 就 是 trunk 子 
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目录 了 。Git 会 











动 地 删除 不 对 这 个 子 目 




















ey 


得 到 了 一 些 没 有 意义 的 子 目 
23K, filter-branch 也 可 以 帮 你 做 到 ; 


H 


























影响 的 提交 。 

















录 (trunk，tags 等 等 ) 


o 














Or 


Scott Chacon Pro Git 6.5% 使 用 Git 调试 











全 局 性 地 更 换 电 子 邮 件 地址 


另 一 

















把 



































个 常见 的 案例 是 你 在 开始 时 起 了 运行 git config 来 设置 你 的 姓名 和 电子 邮件 地 址 ， 也 许 你 想 开 源 一 个 项 
尔 所 有 的 工作 电子 邮件 地 址 修改 为 个 人 地 址 。 无 论 哪 种 情况 你 都 可 以 用 filter-branch 来 更 换 多 次 提交 里 












































































































































gr 








的 电子 
























































b 件 地 址 。 你 必须 小 心 一 些 ， 只 改变 属于 你 的 电子 邮件 地 址 ， 所 以 你 使 





用 --commit-filter: 

















$ git filter-branch --commit-filter ' 


pe 


修改 你 的 历史 中 的 所 有 提交 ， 而 不 仅仅 是 包含 了 匹配 的 电子 邮件 地 址 的 那些 。 


if [ "$GIT AUTHOR EMAIL" = "schacon@localhost" ]; 
then 
GIT AUTHOR NAME-"Scott Chacon"; 
GIT AUTHOR EMAIL-"schaconGexample.com"; 
git commit-tree "$0"; 
else 
git commit-tree "$0"; 
fi' HEAD 





























重 写 所 有 提交 使 之 拥有 你 的 新 地 址 。 因 为 提交 里 包含 了 它们 的 父 提交 的 SHA-1 值 ， 这 个 命令 会 




















(mol 
top 


会 遍历 


























































































































6.5 使 用 Git 调试 


Git 同样 提供 了 一 些 工具 来 帮助 你 调试 项 目 中 遇 到 的 问题 。 由 于 Git 被 设计 为 可 应 用 于 几乎 任何 类 型 的 项 
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LEE 





















































具 是 通用 型 ， 但 是 在 遇 到 问题 时 可 以 经 常 帮助 你 查找 缺陷 所 在 。 

























































































































































































































































































































































































6.5.1 文件 标注 
如 果 你 在 追踪 代码 中 的 缺陷 想 知 道 这 是 什么 时 候 为 什么 被 引进 来 的 ， 文 件 标注 会 是 你 的 最 佳 工具 。 它 会 显示 
文件 中 对 每 一 行进 行 修改 的 最 近 一 次 提交 。 因 此 ， 如 果 你 发 现 自己 代码 中 的 一 个 方法 存在 缺陷 ， 你 可 以 用 git 
blane 来 标注 文件 ， 查 看 那个 方法 的 每 一 行 分 别 是 由 谁 在 哪 一 天 修改 的 。 下 面 这 个 例子 使 用 了 -选项 来 限制 输出 
范围 在 第 12 至 22 行 : 

















$ git blame -L 12,22 simplegit.rb 
^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 12) def show(tree = 'master') 


^4832fe2 (Scott C 
^4832fe2 (Scott C 
^4832fe2 (Scott C 
9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 16) def log(tree = 'master') 
79eaf55d (Scott C 
9f6560e4 (Scott C 
9f6560e4 (Scott C 


hacon 2008-03-15 10:31:28 -0700 13) | command("git show #{tree}") 
hacon 2008-03-15 10:31:28 -0700 14) end 
hacon 2008-03-15 10:31:28 -0700 15) 


hacon 2008-04-06 10:15:08 -0700 17) | command("git log #{tree}") 
hacon 2008-03-17 21:52:20 -0700 18) end 
hacon 2008-03-17 21:52:20 -0700 19) 





42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 20) def blame(path) 
42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21)  command("git blame #{path}") 
42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22) end 


请 注 





















































意 第 一 个 域 里 是 最 后 一 次 修改 该 行 的 那 次 提交 的 SHA-1 f 





。 接 下 去 的 两 个 域 是 从 那 次 提交 中 





取 的 人 

































































FE 者 姓名 和 日 期 一 一 所 以 你 可 以 方便 地 获知 谁 在 什么 时 候 修 改 了 这 一 行 。 在 这 后 面 是 行 号 和 文件 的 内 容 。 
“4832fe2 提 交 的 那些 行 ， 这 些 指 的 是 文件 最 初 提 交 的 那些 行 。 那 个 提交 是 文件 第 一 次 被 加 入 这 个 项 目 时 
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存在 的 ， 自 那 以 后 未 被 修改 过 。 这 会 带 来 小 小 的 困惑 ， 因 为 你 已 经 至 少 看 到 了 Git 使 用 “来 修饰 一 个 提交 的 SHA 
值 的 三 种 不 同 的 意义 ， 但 这 里 确实 就 是 这 个 意思 。 

另 一 件 很 酷 的 事情 是 在 Git 中 你 不 需要 显 式 地 记录 文件 的 重 命名 。 它 会 记录 快照 然后 根据 现实 尝试 找 出 隐 
式 的 重 命名 动作 。 这 其 中 有 一 个 很 有 意思 的 特性 就 是 你 可 以 让 它 找 出 所 有 的 代码 移动 。 如 果 你 在 git blame 后 
加 上 -c，Git 会 分 析 你 在 标注 的 文件 然后 尝试 找 出 其 中 代码 片段 的 原始 出 处 ， 如 果 它 是 从 其 他 地 方 找 贝 过 
来 的 话 。 最 近 ， 我 在 将 一 个 名 叫 GITServerHandler.m 的 文件 分 解 到 多 个 文件 中 ， 其 中 一 个 是 GITPackUpload.m。 通 过 
对 GITPackUpload.m 执 行 带 -Cc 参数 的 blame 命 令 ， 我 可 以 看 到 代码 块 的 原始 出 处 : 
$ git blame -C -L 141,153 GITPackUpload.m 
f344f58d GITServerHandler.m (Scott 2009-01-04 141) 
f344f58d GITServerHandler.m (Scott 2009-01-04 142) - (void) gatherObjectShasFromC 
f344f58d GITServerHandler.m (Scott 2009-01-04 143) ( 
70befddd GITServerHandler.m (Scott 2009-03-22 144) //NSLog(@"GATHER COMMI 
adllac80 GITPackUpload.m (Scott 2009-03-24 145) 
adllac80 GITPackUpload.m (Scott 2009-03-24 146) NSString *parentSha; 
adllac80 GITPackUpload.m (Scott 2009-03-24 147) GITCommit *commit = [g 
adllac80 GITPackUpload.m (Scott 2009-03-24 148) 
adllac80 GITPackUpload.m (Scott 2009-03-24 149) //NSLog(@"GATHER COMMI 
adllac80 GITPackUpload.m (Scott 2009-03-24 150) 
56ef2caf GITServerHandler.m (Scott 2009-01-05 151) if(commit) { 
56ef2caf GITServerHandler.m (Scott 2009-01-05 152) [refDict setOb 
56ef2caf GITServerHandler.m (Scott 2009-01-05 153) 

这 真 的 非常 有 用 。 通 常 ， 你 会 把 你 拷贝 代码 的 那 次 提交 作为 原始 提交 ， 因 为 这 是 你 在 这 个 文件 中 第 一 次 接触 
到 那 几 行 。Git 可 以 告诉 你 编写 那些 行 的 原始 提交 ， 即 便 是 在 另 一 个 文件 里 。 

6.5.2 二 分 查找 

标注 文件 在 你 知道 问题 是 哪里 引入 的 时 候 会 有 帮助 。 如 果 你 不 知道 ， 自 上 次 代码 可 用 的 状态 已 经 经 历 ] 
上 百 次 的 提交 ， 你 可 能 就 要 求助 于 bisect 命 令 了 。bisect 会 在 你 的 提交 历史 中 进行 二 分 查找 来 尽快 地 确定 哪 一 次 
提交 引入 了 错误 。 

列 如 你 刚刚 推送 了 一 个 代码 发 布 版 本 到 产品 环境 中 ， 对 代码 为 什么 会 表现 成 那样 百 思 不 得 其 解 。 你 回 到 你 
的 代码 中 ， 还 好 你 可 以 重 现 那个 问题 ， 但 是 找 不 到 在 哪里 。 你 可 以 对 代码 执行 bisect 来 寻找 。 首 先 你 运行 sit 
bisect start 启 动 然后 你 jgit bisect bad 来 告诉 系统 当 育 HJ 的 提交 已 经 H 问题 J 9 然后 尔 必 须 和 上 告诉 bisect 已 知 的 
最 后 一 次 正常 状态 是 哪 次 提交 ， 使 jgit bisect good [good commit]: 
$ git bisect start 
$ git bisect bad 
$ git bisect good v1.0 
Bisecting: 6 revisions left to test after this 
[ecb6elbc347ccecc5f9350d878ce677febl3d3b2] error handling on repo 

Git 发 现在 你 标记 为 正常 的 提交 (v1.0) 和 当前 的 错误 版 本 之 间 有 大 约 12 次 提交 ， 于 是 它 检 出 中 间 的 一 个 。 在 
这 里 ， 你 可 以 运行 测试 来 检查 问题 是 否 存在 于 这 次 提交 。 如 果 是 ， 那 么 它 是 在 这 个 中 间 提 交 之 前 的 某 一 次 引入 
的 ; 如 果 否 ， 那 么 问题 是 在 中 间 提 交 之 后 引入 的 。 假 设 这 里 是 没有 错误 的 ， 那 么 你 就 通过 git bisect good 来 告诉 
Git 然后 继续 你 的 旅程 
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Scott Chacon Pro Git 6.5% 使 用 Git 调试 








$ git bisect good 
Bisecting: 3 revisions left to test after this 


[5047502ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing 




















现在 你 在 另外 一 个 提交 上 了 ， 在 你 刚刚 测试 通过 的 和 一 个 错误 提交 的 中 点 处 。 你 再 次 运行 测试 然后 发 现 这 次 


提交 是 错误 的 ， 因 此 你 通过 git bisect bad 来 告诉 Git: 













































































$ git bisect bad 
Bisecting: 1 revisions left to test after this 


[£71ce38690acf49clf3c9bea38e09d82a5ce6014] drop exceptions table 



































这 次 提交 是 好 的 ， 那 么 Git 就 获得 了 确定 问题 引入 位 置 所 需 的 所 有 信息 。 它 告诉 你 第 一 个 错误 提交 的 SHA-1 
显示 一 些 提 交 说 明 以 及 哪些 文件 在 那 次 提交 里 修改 过 ， 这 样 你 可 以 找 出 缺陷 被 引入 的 根源 : 
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III 


























$ git bisect good 

b047502ea83310a70fd603dc8cd7a6cd13dl5c04 is first bad commit 
commit b047b02ea83310a70fd603dc8cd7a6cd13d15c04 

Author: PJ Hyett <pjhyett@example.com> 

Date: Tue Jan 27 14:48:32 2009 -0800 


secure this thing 


:040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730 
f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config 











当 你 完成 之 后 ， 你 应 该 运行 git bisect reset 来 重 设 你 的 EAD 到 你 开始 前 的 地 方 ， 否 则 你 会 处 于 一 个 诡异 的 地 
方 : 


























$ git bisect reset 






































`+ 





这 是 个 强大 的 工具 ， 可 以 帮助 你 检查 上 百 的 提交 ， 在 几 分 钟 内 找 出 缺陷 引入 的 位 置 。 事 实 上 ， 如 果 你 有 一 个 
脚本 会 在 工程 正常 时 返回 9， 错 误 时 返回 非 0 的 话 ， 你 可 以 完全 自动 地 执行 git bisect。 首 先 你 需要 提供 已 知 的 错 
误 和 正确 提交 来 告诉 它 二 分 查找 的 范围 。 你 可 以 通过 bisect start 命 令 来 列 出 它们 ， 先 列 出 已 知 的 错误 提交 再 列 



































































































































































































































ey 

































































$ git bisect start HEAD v1.0 


$ git bisect run test-error.sh 























这 样 会 自动 地 在 每 一 个 检 出 的 提交 里 运行 test-error.sh 直 到 Git 找 出 第 一 个 破损 的 提交 。 你 也 可 以 运行 像 make 或 
者 make tests 或 者 任何 你 所 拥有 的 来 为 你 执行 自动 化 的 测试 。 
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6.6 子 模块 
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经 常 有 这 样 的 事情 ， 当 你 在 一 个 项 目 上 工作 时 ， 你 需要 在 其 中 使 用 另外 一 个 项 目 。 也 许 它 是 一 个 第 三 方 开发 
的 库 或 者 是 你 独立 开发 和 并 在 多 个 父 项 目 中 使 用 的 。 这 个 场景 下 一 个 常见 的 问题 产生 了 : 你 想 将 两 个 项 目 单独 
处 理 但 是 又 需要 在 其 中 一 个 中 使 用 另外 一 个 。 

这 里 有 一 个 例子 。 假 设 你 在 开发 一 个 网 站 ， 为 之 创建 Atom 源 。 你 不 想 编 写 一 个 自己 的 Atom 生 成 代码 ， 而 是 决 
定 使 用 一 个 库 。 你 可 能 不 得 不 像 CPAN install 或 者 Ruby genm 一 样 包含 来 自 共享 库 的 代码 ， 或 者 将 代码 拷贝 到 你 
的 项 目 树 中 。 如 果 采 用 包含 库 的 办 法 ， 那 么 不 管用 什么 办 法 都 很 难 去 定制 这 个 库 ， 部 署 它 就 更 加 困难 了 ， 因 为 
你 必须 确保 每 个 客户 都 拥有 那个 库 。 把 代码 包含 到 你 自己 的 项 目 中 带 来 的 问题 是 ， 当 上 游 被 修改 时 ， 任 何 你 进 
行 的 定制 化 的 修改 都 很 难 归并 。 

Git 通过 子 模块 处 理 这 个 问题 。 子 模块 允许 你 将 一 个 Git 仓库 当 作 另 外 一 个 Git 仓 库 的 子 目录 。 这 人 允许 你 克 
隆 另 外 一 个 仓库 到 你 的 项 目 中 并 且 保持 你 的 提交 相对 独立 。 

6.6.1 子 模块 初步 

假设 你 想 把 Rack Æ (一 个 Ruby 的 web 服务 器 网 关 接 口 ) 加 入 到 你 的 项 目 中 ， 可 能 既 要 保持 你 自己 的 变 
更 ， 又 要 延续 上 游 的 变更 。 首 先 你 要 把 外 部 的 仓库 克隆 到 你 的 子 目录 中 。 你 通过 git submodule add 将 外 部 项 目 加 
为 子 模块 : 
$ git submodule add git://github.com/chneukirchen/rack.git rack 
Initialized empty Git repository in /opt/subtest/rack/.git/ 
remote: Counting objects: 3181, done. 
remote: Compressing objects: 100% (1534/1534), done. 
remote: Total 3181 (delta 1951), reused 2623 (delta 1603) 

Receiving objects: 100% (3181/3181), 675.42 KiB | 422 KiB/s, done. 
Resolving deltas: 100% (1951/1951), done. 

现在 你 就 在 项 目 里 的 rack 子 目录 下 有 了 一 个 Rack 项 目 。 你 可 以 进入 那个 子 目录 ， 进 行 变更 ， 加 入 你 自己 的 
远程 可 写 仓库 来 推送 你 的 变更 ， 从 原始 仓库 拉 取 和 归并 等 等 。 如 果 你 在 加 入 子 模块 后 立刻 运行 sit status, WÈ 
看 到 下 面 两 项 : 


























$ git status 
# On branch master 


# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 
# 

# new file: .gitmodules 

# new file: rack 

# 



































Si 
am 


首先 你 注意 到 有 一 个 .gitmodules 文 件 。i 
































$ cat .gitmodules 
[submodule "rack" | 
path = rack 
url = git://github.com/chneukirchen/rack. git 
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个 配置 文件 ， 保 存 了 项 目 URL 和 你 拉 取 到 的 本 地 子 目 录 

















Scott Chacon Pro Git 6.69 子 模块 























H 
xh 
P 
HE 




















如 果 你 有 多 个 子 模块 ， 这 个 文件 里 会 有 多 个 条 目 。 很 重要 的 一 点 是 这 个 文件 跟 其 他 文件 一 样 也 是 处 了 
制 之 下 的 ， 就 像 你 的 .gitignore 文 件 一 样 。 它 跟 项 目 里 的 其 他 文件 一 样 可 以 被 推送 和 拉 取 。 这 是 其 他 克隆 此 项 
的 人 获知 子 模块 项 目 来 源 的 途径 。 
git status 的 输出 里 所 列 的 另 一 项 目 是 rack 。 如 有 果 你 运行 在 那 上 面 运行 sit diff， 会 发 现 一 些 有 趣 的 东西 : 
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$ git diff --cached rack 

diff --git a/rack b/rack 

new file mode 160000 

index 0000000..08d709f 

--- /dev/null 

+++ b/rack 

QQ@ -0,0 +1 eo 

+Subproject commit 08d709f78b8c5b0fbeb7821e37fab3e69afcf433 




























































































尽管 rack 是 你 工作 目录 里 的 子 目 录 , 但 Git 把 它 视 作 一 个 子 模块 ， 当 你 不 在 那个 目录 里 时 并 不 记录 它 的 内 
容 。 取 而 代 之 的 是 ，Git 将 它 记 录 成 来 自 那 个 仓库 的 一 个 特殊 的 提交 。 当 你 在 那个 子 目 录 里 修改 并 提交 时 ， 子 
项 目 会 通知 那里 的 HEAD 已 经 发 生变 更 并 记录 你 当前 正在 工作 的 那个 提交 ; 通过 那样 的 方法 ， 当 其 他 人 克隆 此 
项 目 ， 他 们 可 以 重新 创建 一 致 的 环境 。 
这 是 关于 子 模块 的 重要 一 点 : 你 记录 他 们 当前 确切 所 处 的 提交 。 你 不 能 记录 一 个 子 模块 的 naster 或 者 其 他 的 
符号 引用 。 
当 你 提交 时 ， 会 看 到 类 似 下 面 的 




























































































































































































































































































$ git commit -m 'first commit with submodule rack' 
[master 0550271] first commit with submodule rack 
2 files changed, 4 insertions(+), 0 deletions(-) 
create mode 100644 .gitmodules 
create mode 160000 rack 



























































注意 rack 条 目的 160000 模式 。 这 在 Git 中 是 一 个 特殊 模式 ， 基 本 意思 是 你 将 一 个 提交 记录 为 一 个 目录 项 
而 不 是 子 目 录 或 者 文件 。 
你 可 以 将 rack 目 录 当 作 一 个 独立 的 项 目 ， 保 持 一 个 指向 子 目 录 的 最 新 提交 的 指针 然后 反复 地 更 新 上 层 项 目 。 


所 有 的 Git 命 令 都 在 两 个 子 目录 里 独立 工作 : 

















































































































































































































$ git log -1 
commit 0550271328a0038865aad6331e620cd7238601bb 
Author: Scott Chacon <schacon@gmail.com> 


Date: Thu Apr 9 09:03:56 2009 -0700 


first commit with submodule rack 
$ cd rack/ 
$ git log -1 
commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433 
Author: Christian Neukirchen <chneukirchen@gmail.com> 


Date: Wed Mar 25 14:49:04 2009 +0100 


Document version change 
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6.6.2 克隆 一 个 带子 模块 的 项 目 
这 里 你 将 克隆 一 个 带子 模块 的 项 目 。 当 你 接收 到 这 样 一 个 项 目 ， 你 将 得 到 了 包含 子 项 目的 目录 ， 但 里 
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nt 


























$ git clone git://github.com/schacon/myproject.git 
Initialized empty Git repository in /opt/myproject/.git/ 
remote: Counting objects: 6, done. 

remote: Compressing objects: 100% (4/4), done. 
remote: Total 6 (delta 0), reused 0 (delta 0) 
Receiving objects: 100% (6/6), done. 

$ cd myproject 

$ 1s -1 

total 8 

-rw-r-r-- 1 schacon admin 3 Apr 9 09:11 README 
drwxr-xr-x 2 schacon admin 68 Apr 9 09:11 rack 
$ 1s rack/ 

$ 














rack H 3 FET, 但 是 是 空 的 9 你 必须 运行 VT ge: git submodule init 来 初始 化 你 的 本 地 配置 文件 ， git 
submodule update 来 从 那个 项 目 拉 取 所 有 数据 出 你 上 层 项 目 里 所 列 的 合适 的 提交 : 
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$ git submodule init 

Submodule 'rack' (git://github.com/chneukirchen/rack.git) registered for path 'rack' 
$ git submodule update 

Initialized empty Git repository in /opt/myproject/rack/.git/ 

remote: Counting objects: 3181, done. 

remote: Compressing objects: 100% (1534/1534), done. 

remote: Total 3181 (delta 1951), reused 2623 (delta 1603) 

Receiving objects: 100% (3181/3181), 675.42 KiB | 173 KiB/s, done. 

Resolving deltas: 100% (1951/1951), done. 

Submodule path 'rack': checked out '08d709f78b8c5bO0fbeb7821e37fa53e69afcf433' 















































现在 你 的 rack 子 目录 就 处 于 你 先前 提交 的 确切 状态 了 。 如 果 另 外 一 个 开发 者 变更 了 rack 的 代码 并 提交 ， 你 
拉 取 那个 引用 然后 归并 之 ， 将 得 到 稍 有 点 怪异 的 东西 : 












































































































































$ git merge origin/master 
Updating 0550271..85a3eee 
Fast forward 
rack | Que 
1 files changed, 1 insertions(+), 1 deletions(-) 
[master*]$ git status 
# On branch master 


# Changed but not updated: 


# (use "git add <file>..." to update what will be committed) 

# (use "git checkout -- <file>..." to discard changes in working directory) 
# 

# modified: rack 

# 
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你 归并 来 的 仅仅 上 是 一 个 指向 你 的 子 模块 的 指针 ， 但 是 它 并 不 更 新 你 子 模块 目录 里 的 代码 ， 所 以 看 起 来 你 的 
作 目 录 处 于 一 个 临时 状态 : 






























































$ git diff 

diff --git a/rack b/rack 

index 6c5e70b..08d709f 160000 

--- a/rack 

+++ b/rack 

eo -1 +1 eo 

-Subproject commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 
+Subproject commit 08d709f78b8c5b0fbeb7821e37fab53e69afcf433 



























































事情 就 是 这 样 ， 因 为 你 所 拥有 的 子 模块 的 指针 并 对 应 于 子 模块 目录 的 真实 状态 。 为 了 修复 这 一 点 ， 你 必须 再 


次 运 Jgit submodule update: 



























































$ git submodule update 
remote: Counting objects: 5, done. 
remote: Compressing objects: 100% (3/3), done. 
remote: Total 3 (delta 1), reused 2 (delta 0) 
Unpacking objects: 100% (3/3), done. 
From git@github.com:schacon/rack 
08d709f..6c5e70b master -> origin/master 
Submodule path 'rack': checked out '6c5e70b984a60b3cecd395edd5b48a7575bf58e0' 
































每 次 你 从 主 项 目 中 拉 取 一 个 子 模块 的 变更 都 必须 这 样 做 。 看 起 来 很 怪 但 是 管用 。 

一 个 常见 问题 是 当 开 发 者 对 子 模块 做 了 一 个 本 地 的 变更 但 是 并 没有 推送 到 公共 服务 器 。 然 后 他 们 提交 了 一 个 
指向 那个 非 公开 状态 的 指针 然后 推送 上 层 项 目 。 当 其 他 开发 者 试图 运行 fit submodule update， 那 个 子 模块 系统 会 
找 不 到 所 引用 的 提交 ， 因 为 它 只 存在 于 第 个 开发 者 的 系统 中 。 如 有 果 发 生 那 种 情况 ， 你 会 看 到 类 似 这样 的 错 
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$ git submodule update 
fatal: reference isn’ t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 
Unable to checkout '6c5e70b984a60b3cecd395eddbba7575bf58e0' in submodule path 'rack' 


ith 

















你 不 得 不 去 i E 最 后 变更 了 子 模块 









































$ git log -1 rack 
commit 85a3eee996800fcfa91e2119372dd4172bf76678 
Author: Scott Chacon <schacon@gmail.com> 


Date: Thu Apr 9 09:19:14 2009 -0700 


added a submodule reference I will never make public. hahahahaha! 















































然后 ， 你 给 那个 家 伙 发 电 
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p 件 说 他 一 通 。 
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6.6.3 上 层 项 目 



































有 时候 ， 开 发 者 想 按照 他 们 的 分 组 获取 一 个 大 项 目的 子 目 录 的 子 集 。 如 果 你 是 从 CVS 或 者 Subversion if 
移 过 来 的 话 这 个 很 常见 ， 在 那些 系统 中 你 已 经 定义 了 一 个 模块 或 者 子 目录 的 集合 ， 而 你 想 延 续 这 种 类 型 的 工作 
在 Git 中 实现 这 个 的 一 个 好 办 法 是 你 将 每 一 个 子 目录 都 做 成 独立 的 Git 仓库 ， 然 后 创建 一 个 上 层 项 目的 
Git 仓库 包含 多 个 子 模块 。 这 个 办 法 的 一 个 优势 是 你 可 以 在 上 层 项 目 中 通过 标签 和 分 支 更 为 明确 地 定义 项 目 之 
间 的 关系 。 




















































































































































































































































































































6.6.4 子 模块 的 问题 




















区 用 子 模块 并 非 没 有 任何 缺点 。 首先 ， 你 在 子 模块 目录 中 工作 时 必须 相对 小 心 。 当 你 运行 git submodule 
update， 它 会 检 出 项 目的 指定 版 本 ， 但 是 不 在 分 文 内 。 这 叫做 获得 一 个 分 离 的 头 一 一 这 意味 着 HEAD 文件 直接 
站 向 一 次 提交 ， 而 不 是 一 个 符号 引用 。 问 题 在 于 你 通常 并 不 想 在 一 个 分 离 的 头 的 环境 下 工作 ， 因 为 太 容易 丢失 
变更 了 。 如 果 你 先 执行 了 一 次 submodule update， 人 然后 在 那个 子 模块 目录 里 不 创建 分 文 就 进行 提交 ， 然 后 再 次 从 
上 层 项 目 里 运行 sit submodule update 同 时 不 进行 提交 ，Git 会 党 无 提示 地 歼 盖 你 的 变更 。 技 术 上 讲 你 不 会 丢失 工 
作 ， 但 是 你 将 失去 指向 它 的 分 文 ， 因 此 会 很 难 取 到 

为 了 避免 这 个 问题 ， 当 你 在 子 模块 目录 里 工作 时 应 使 用 git checkout -b 创 建 一 个 分 支 。 当 你 再 次 在 子 模块 里 更 
新 的 时 候 ， 它 仍然 会 覆盖 你 的 工作 ， 但 是 至 少 你 拥有 一 个 可 以 回溯 的 指针 

切换 带 有 子 模块 的 分 文 同样 也 很 有 技巧 。 如 果 你 创建 一 个 新 的 分 文 ， 增 加 了 一 个 子 模块 ， 然 后 切换 回 不 带 该 
子 模块 的 分 支 ， 你 仍然 会 拥有 一 个 未 被 追踪 的 子 模块 的 目录 
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$ git checkout -b rack 

Switched to a new branch "rack" 

$ git submodule add gitegithub.com:schacon/rack.git rack 
Initialized empty Git repository in /opt/myproj/rack/.git/ 


Receiving objects: 100% (3184/3184), 677.42 KiB | 34 KiB/s, done. 
Resolving deltas: 100% (1952/1952), done. 
$ git commit -am 'added rack submodule' 
[rack cc49a69] added rack submodule 
2 files changed, 4 insertions(+), 0 deletions(-) 
create mode 100644 .gitmodules 
create mode 160000 rack 
$ git checkout master 
Switched to branch "master" 


$ git status 





# On branch master 


# Untracked files: 


# (use "git add <file>..." to include in what will be committed) 
# 
# rack/ 























你 将 不 得 不 将 它 移 走 或 者 删除 ， 这 样 的 话 当 你 切换 回去 的 时 候 必须 重新 克隆 它 一 一 你 可 能 会 丢失 你 未 推送 的 
本 地 的 变更 或 分 文 。 

最 后 一 个 需要 引起 注意 的 是 关于 从 子 目录 切换 到 子 模块 的 。 如 果 你 已 经 跟踪 了 你 项 目 中 的 一 些 文 件 但 是 想 把 
它们 移 到 子 模块 去 ， 你 必须 非常 小 心 ， 否 则 Git 会 生 你 的 气 。 假 设 你 的 项 目 中 有 一 个 子 目录 里 放 了 rack 的 文 
件 ， 然 后 你 想 将 它 转 换 为 子 模块 。 如 果 你 删除 子 目 录 然 后 运行 submodule add, Git SHAUL: 
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$ rm -Rf rack/ 
$ git submodule add gitegithub.com:schacon/rack.git rack 


'rack' already exists in the index 











你 必须 先 将 rack 目 录 撤 回 。 然 后 你 才能 加 入 子 模块 ; 























$ git rm -r rack 

$ git submodule add gitegithub.com:schacon/rack.git rack 
Initialized empty Git repository in /opt/testsub/rack/.git/ 
remote: Counting objects: 3184, done. 

remote: Compressing objects: 100* (1465/1465), done. 

remote: Total 3184 (delta 1952), reused 2770 (delta 1675) 
Receiving objects: 100% (3184/3184), 677.42 KiB | 88 KiB/s, done. 
Resolving deltas: 100% (1952/1952), done. 
















































































现在 假设 你 在 一 个 分 文 里 那样 做 了 “。 如 果 你 尝试 切换 回 一 个 仍然 在 目录 里 保留 那些 文件 而 不 是 子 模块 的 分 支 





















































时 一 一 你 会 得 到 下 面 的 错误 : 




















$ git checkout master 


error: Untracked working tree file 'rack/AUTHORS' would be overwritten by merge. 

















你 必须 先 移 除 rack 子 模块 的 目录 才能 切换 到 不 包含 它 的 分 支 : 











$ mv rack /tmp/ 

$ git checkout master 
Switched to branch "master" 
$ 1s 

README rack 




















然后 ， 当 你 切换 回来 ， 你 会 得 到 一 个 空 的 rack 目 录 。 你 可 以 运行 fit submodule update 重 新 克隆 ， 也 可 以 将 /tmp/ 













































































rack H 录 重 新 移 可 空 目录 e 

















6.7 子 树 合并 







































































































































































































































































































































































































































































现在 你 已 经 看 到 了 子 模块 系统 的 麻烦 之 处 ， 让 我 们 来 看 一 下 解决 相同 问题 的 另 一 途径 。 当 Git 归并 时 ， 它 
会 检查 需要 归并 的 内 容 然 后 选择 一 个 合适 的 归并 策略 。 如 果 你 归并 的 分 支 是 两 个 ，Git 使 用 一 个 _ 递归 策略 。 
如 果 你 归并 的 分 支 超过 两 个 ，Git 采 用 _ 章 鱼 _ 策略。 这些 策 略 是 自动 选择 的 ， 因 为 递归 策略 可 以 处 理 复杂 的 三 
路 归并 情况 一 一 比如 多 于 一 个 共同 祖先 的 一 一 但 是 它 只 能 处 理 两 个 分 支 的 归并 。 章 鱼 归并 可 以 处 理 多 个 分 支 但 
是 但 必须 更 加 小 心 以 避免 冲突 带 来 的 麻烦 ， 因 此 它 被 选中 作为 归并 两 个 以 上 分 支 的 默认 策略 。 

实际 上 ， 你 也 可 以 选择 其 他 策略 。 其 中 的 一 个 就 是 _ 子 树 _ 归 并 ， 你 可 以 用 它 来 处 理子 项 目 问题 。 这 里 你 会 看 


































































































到 如 何 换 用 子 树 归并 的 方法 来 实现 前 一 节 里 所 做 的 rack AERA ° 























































































































子 树 归 并 的 思想 是 你 拥有 两 个 工程 ， 其 中 一 个 项 目 映射 到 另外 一 个 项 目的 子 目 录 中 ， 反 过 来 也 一 样 。 当 你 指 














































































































定 一 个 子 树 归并 ，Git 可 以 聪明 地 探知 其 中 一 个 是 另外 一 个 的 子 树 从 而 实现 正确 的 归 这 相当 神奇 。 
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首先 你 将 Rack 应 用 加 入 到 项 
oP x: 























。 你 将 Rack 项 目 当 作 你 项 目 中 的 一 个 远程 引用 ， 






































$ git remote add rack remote git@github.com:schacon/rack. git 


$ git fetch rack_remote 


warning: 


no common commits 


remote: Counting objects: 3184, done. 

remote: Compressing objects: 100% (1465/1465), done. 

remote: Total 3184 (delta 1952), reused 2770 (delta 1675) 
Receiving objects: 100% (3184/3184), 677.42 KiB | 4 KiB/s, done. 


Resolving deltas: 100% (1952/1952), 


From git@github.com:schacon/rack 


* [new 
* [new 
* [new 


* [new 


$ git checkout -b rack_branch rack_ 


branch | build > 
branch | master -- 
branch] rack-0.4 ct 
branch] rack-0.9 ums 


done. 


rack remote/build 
rack remote/master 
rack remote/rack-0.4 
rack remote/rack-0.9 


remote/master 


Branch rack branch set up to track remote branch refs/remotes/rack remote/master. 


Switched to a new branch "rack branch" 


现在 











了 


Scot 


t Chacon Pro Git 











尖 后 将 它 检 出 到 它 自 身 









































在 你 的 rack_branch 分 支 中 就 有 了 Rack 项 目的 根 目录 ， 而 你 自己 的 项 目 在 naster 分 支 ! 




















一 个 然 


TON 


$ 1s 
AUTHORS 
COPYING 


















































后 另外 一 个 ， 你 会 看 到 它们 有 不 同 的 项 目 根 目录 : 








KNOWN-ISSUES Rake 
README bin 


$ git checkout master 


Switched to branch "master" 


$ 1s 
README 


要 将 Rack 项 目 当 作 子 目录 拉 取 到 你 的 master 项 目 中 。 你 可 以 在 Git 中 用 git read-tree3l 




















file contrib lib 


example test 
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KE 实现。 你 会 在 第 9 
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$ git read-tree --prefix-rack/ -u rack branch 





当 你 提交 的 时 




















HR, WERNA 











































































































有 意思 的 是 你 可 以 比较 容易 














过 切换 到 那个 分 支 并 执行 拉 取 






















































































$ git checkout rack branch 


$ git pull 





然后 ， 你 可 以 将 那些 变更 归 
] 时 会 把 历史 归并 到 一 起 ， 








获得 上 游 的 变更 ; 






















































































回 你 的 master 分 支 o 你 可 以 使 用 git merge -s subtree, 





ETHER M SHS SE SER o AU, NFR Rack 项 


更 多 与 read-tree 和 它 的 朋友 相关 的 东西 ， 当 前 你 会 知道 它 读 取 一 个 分 支 的 根 目 录 树 到 当前 的 暂 存 区 和 
。 你 只 要 切换 回 你 的 master 分 支 ， 然 后 拉 取 rack 分 支 到 你 主 项 目的 master 分 支 的 rack 子 有 目 

















尔 在 那个 子 目录 下 拥有 Rack 的 文件 一 一 就 像 你 从 一 个 tarball 





























里 拷贝 的 一 样 。 
































它 会 工作 的 很 好 ; 但 是 


更 新 了 ， 你 可 以 通 




















> 
































这 可 能 不 是 你 想 要 的 。 为 了 拉 取 变更 并 预 置 提交 说 明 ， 

















时 使 j --squash 和 --no-commit 选 项 p: 





Æ-s subtree 策 略 选 
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$ git checkout master 
$ git merge --squash -s subtree --no-commit rack branch 
Squash commit -- not updating HEAD 


Automatic merge went well; stopped before committing as requested 





















































UH Rack 项 目的 变更 都 被 归并 可 以 进行 本 地 提交 。 你 也 可 以 做 相反 的 事情 一 一 在 你 主 分 支 的 rack 目 录 里 进 
行 变更 然后 归并 回 rack_branch 分 支 ， 然 后 将 它们 提交 给 维护 者 或 者 推送 到 上 游 。 
为 了 得 到 rack 子 目录 和 你 rack_branch 分 支 的 区 别 一 一 以 决定 你 是 否 需要 归并 它们 一 一 你 不 能 


令 。 而 是 对 你 想 比较 的 分 支 运 行 git diff-tree: 






























































































































































一 般 的 diff 命 











—— 
二 






































$ git diff-tree -D rack_branch 

















或 者 ， 为 了 比较 你 的 rack 子 目录 和 服务 器 上 你 拉 取 时 的 master 分 支 ， 你 可 以 运行 




















$ git diff-tree -p rack remote/master 


O 
oo 
x 
ae 


























你 已 经 看 到 了 很 多 高 级 的 工具 ， 人 允许 你 更 加 精确 地 操控 你 的 提交 和 和 暂 存 区 。 当 你 碰 到 问题 时 ， 你 应 该 可 以 逢 
容易 找 出 是 哪个 分 文 什么 时 候 由 谁 引 入 了 它们 。 如 果 你 想 在 项 目 中 使 用 子 项 目 ， 你 也 已 经 学 会 了 一 些 方法 来 满 
些 需求 。 到 此 ， 你 应 该 能 够 完成 日 常 里 你 需要 用 命令 行 在 Git 下 做 的 大 部 分 事情 ， 并 且 感 到 比较 顺手 。 





wo 


























































































































































































































iu 














au 
be 8 
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É x 3 Git 


























Not 





































































































到 目前 为 止 ， 我 阐述 了 Git 基本 的 运作 机 制 和 使 用 方式 ， 介 绍 了 Git 提供 的 许多 工具 来 帮助 你 简单 且 有 效 
地 使 用 它 。 在 本 章 当 中 ， 我 将 会 介绍 Git 的 一 些 重要 的 配置 方法 和 钩子 机 制 以 满足 你 自 定义 的 要 求 ， 通 过 这 
些 方法 ， 它 会 和 你 、 你 的 公司 或 团队 配合 得 天 衣 无 颖 。 
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7.1 配置 Git 























































































































正如 你 在 第 一 章 见 到 的 那样 ， 你 能 用 git config 配 置 Git， 要 做 的 第 一 件 事 就 是 设置 名 字 和 邮箱 地 址 : 








$ git config --global user.name "John Doe" 


$ git config --global user.email johndoe@example.com 























从 现在 开始 ， 你 会 了 解 到 一 些 更 为 有 趣 的 设置 选项 ， 按 照 以 上 方式 来 自 定义 Gite 

我 会 在 这 先 过 一 遍 第 一 章 中 提 到 的 Git 配置 细节 。Git 使 用 一 系列 的 配置 文件 来 存储 你 定义 的 偏好 ， 它 
首先 会 查找 /etc/gitconfig 文 件 ， 该 文件 含有 对 系统 上 所 有 用 户 及 他 们 所 拥有 的 仓库 都 生效 的 配置 值 (译注 : 
gitconfig 是 全 局 配置 文件 ， 如 果 传 递 --systen 选 项 给 git config 命 令 ， Git 会 读 写 这 个 文件 。 

接 下 来 Git 会 查找 每 个 用 户 的 -/.gitconfig 文 件 ， 你 能 传递 --global 选 项 让 Git 读 写 该 文件 。 

最 后 Git 会 查找 由 用 户 定 义 的 各 个 库 中 Git 目录 下 的 配置 文件 (.git/config) ， 该 文件 中 的 值 只 对 属 主 库 
有 效 。 以 上 阐述 的 三 层 配 置 从 一 般 到 特殊 层 层 推进 ， 如 果 定 义 的 值 有 冲突 ， 以 后 面 层 中 定义 的 为 准 ， 例 如 : 
TE .git/config#il/etc/gitconfigh Px it/config 取 得 了 胜利 。 虽 然 你 也 可 以 直接 手动 编辑 这 些 配置 文件 ，{ 


^ A jE ABUS 
令 将 会 来 得 简单 
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是 运行 git config 命 





7.1.1 客户 端 基 本 配置 





















































Git 能 够 识别 的 配置 项 被 分 为 了 两 大 类 : 客户 端 和 服务 器 端 ， 其 中 大 部 分 基于 你 个 人 工作 偏好 ， 属 于 客户 端 
配置 。 尽 管 有 数 不 尽 的 选项 ， 但 我 只 阐述 其 中 经 常 使 用 或 者 会 对 你 的 工作 流产 生 巨 大 影响 的 选项 ， 如 果 你 想 
观察 你 当前 的 Git 能 识别 的 选项 列表 ， 请 运行 

















































































































































































































$ git config --help 




















git config 的 手册 页 (译注 ， 以 man 命 令 的 显示 方式 ) 非常 细致 地 罗列 了 所 有 可 用 的 配置 项 。 
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core.editor 


Git 默 认 会 调用 





Scott Chacon Pro Git 






































尔 的 环境 变量 editor 定 义 的 值 作为 文本 编辑 器 ， 如 果 没 有 定义 的 话 ， 会 调用 Vi 来 创建 和 编辑 





























提交 以 及 标签 信息 ， 你 可 以 使 用 core.editor 改 变 默认 编辑 器 : 


$ git config --global core.editor emacs 


现在 无 论 你 的 环境 变量 editor 被 定义 成 什么 ，Git 都 会 调用 ] 





commit.template 













































































如 果 把 此 项 指定 为 你 系统 上 的 一 个 文件 ， 当 你 提交 的 时 候 ， 














创建 了 一 个 模板 文件 $HOME/ .gitmessage.txt, 它 看 起 来 像 这 样 : 


subject line 


what happened 


[ticket: X] 
































Emacs 编辑 信息 。 





D 











Git 会 默认 使 用 该 文件 定义 的 内 容 。 例如 : 你 












































设置 commit.template， 当 运 行 git commi tH] , Git 会 在 你 的 编 辑 器 显示 以 上 的 内 容 ， 设置 commit.template 如 





下 : 














$ git config --global commit.template $HOME/.gitmessage.txt 


$ git commit 























然后 当 你 提交 时 ， 在 


subject line 


what happened 


[ticket: X] 

















d 












































辑 器 中 显示 的 提交 信息 如 下 ; 


# Please enter the commit message for your changes. Lines starting 


# with '£' will be ignored, and an empty message aborts the commit. 


# On branch master 


# Changes to be committed: 


# (use "git reset HEAD <file>..." to unstage) 


# 


# modified: lib/test.rb 


# 


".git/COMMIT EDITMSG" 14L, 297C 





























如 果 你 有 特定 的 策略 要 运用 在 提交 信息 上 ， 厂 
































交 时 ， 你 的 策略 每 次 都 会 被 运用 。 
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pn 

















系统 上 创建 一 个 模板 文件 ， 设 置 Git 默认 使 用 它 ， 这 样 当 提 
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core.pager 

















core.pager 指 定 Git 运行 诸如 1og、diff 等 所 使 用 的 分 页 器 ， 你 能 设置 成 用 more 或 者 任何 你 喜欢 的 分 页 器 (BR 
认 用 的 是 less) ， 当然 你 也 可 以 什么 都 不 用 ， 设 置 空 字符 串 ; 




































































$ git config --global core.pager '' 








这 样 不 管 命令 的 输出 量 多 少 ， 都 会 在 一 页 显示 所 有 内 


m 














user.signingkey 





















































如 果 你 要 创建 经 签署 的 含 附注 的 标签 〈 正 如 第 二 章 所 述 ) ， 那 么 把 你 的 GPG 签 署 密 钥 设 置 为 配置 项 会 更 好 ， 
设置 密 钥 ID 如 下 : 












































$ git config --global user.signingkey <gpg-key-id> 


现在 你 能 够 签署 标签 ， 从 而 不 必 每 次 运行 sit tag 命 令 时 定义 密 钥 : 











$ git tag -s <tag-name> 


core.excludesfile 






























































正如 第 二 章 所 述 ， 你 能 在 项 目 库 的 .gitignore 文 件 里 头 用 模式 来 定义 那些 无 需 纳 入 Git 管理 的 文件 ， 这 样 它 
们 不 会 出 现在 未 跟踪 列表 ， 也 不 会 在 你 运行 sit add 后 被 暂 存 。 然 而 ， 如 果 你 想 用 项 目 库 之 外 的 文件 来 定义 那 
些 需 被 忽略 的 文件 的 话 ， 用 core.excludesfile 通知 Git 该 文件 所 处 的 位 置 ， 文件 内 容 和 .gitignore 类 化 s 


















































































































































help.autocorrect 

















该 配置 项 只 在 Git 1.6.1 及 以 上 版 本 有 效 ， 假 如 你 在 Git 1.6 中 错 打 了 一 条 命令 ， 会 显示 : 






































$ git com 


git: 'com' is not a git-command. See 'git --help'. 


Did you mean this? 


commit 















































如 果 你 把 help.autocorrect 设 置 成 1 (译注 ， 启 动 自动 修正 ) ， 那 么 在 只 有 一 个 命令 被 模糊 匹配 到 的 情况 
下 ，Git 会 自动 运行 该 命令 。 













































































7.1.2 Git 中 的 着 色 


Git 能 够 为 输出 到 你 终端 的 内 容 着 色 ， 以 便 你 可 以 赁 直观 进行 快速 、 简 单 地 分 析 ， 
符合 你 的 偏好 。 













































































amt 


许多 选项 能 供 你 使 用 以 
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color.ui 

















Git 会 按照 你 需要 自动 为 大 部 分 的 输出 加 上 颜色 ， 你 能 明确 地 规定 哪些 需要 着 1 














置 color.ui 为 true 来 打开 所 有 的 默认 终端 着 色 。 
































$ git config --global color.ui true 





设置 好 以 后 ， 当 输出 到 终端 时 ，Git 22 JU EB 
出 着 色 ， 而 always 则 表明 在 任何 情况 下 都 要 着 色 ， 即 使 Git 命令 被 重 定向 到 文件 
进 了 此 项 配置 ， 如 果 你 拥有 的 版 本 更 老 ， 你 必须 对 颜色 




















L| 
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Li 




















































































































color.* 
































尔 会 很 少 用 到 color.ui = always， 在 大 多 数 情 况 F, And 
color 标 志 给 Git 命令 来 迫使 它 这 么 做 ， color.ui - true 应 该 是 你 ` 





















































想 要 具体 到 哪些 命令 输出 需要 被 着 色 以 及 怎样 着 
色 配 置 选 项 ， 它们 都 能 被 置 为 true 、false 或 always: 


















































color .branch 
color.diff 
color.interactive 


color.status 




















色 或 者 Git 的 版 本 很 老 ， 你 就 要 用 















































除 此 之 外 ， 以 上 每 个 选项 都 有 子 选项 ， 可 以 被 用 






































置 ， 以 达到 为 输出 的 各 个 部 分 着 色 的 目 



























































例如 ， 让 diff 输 出 的 改变 信息 以 粗 体 、 蓝 色 前 景 和 黑 























$ git config --global color.diff.meta “blue black bold” 





你 能 设置 的 颜色 值 如 : normal 、black、red、green、yellow、blue、magenta、 cyan ` white, 
子 设置 的 粗 体 属 性 ， 想 要 设置 字体 属性 的 话 ， 可 以 选择 如 : bold、dim、ul、blink、reverse。 
如 果 你 想 配置 子 选项 的 话 ， 可 以 参考 git config 帮 助 页 。 


























































































































7.1.3 外 部 的 合并 与 比较 工具 
























































虽然 Git 实现 了 diff ,而 且 到 目前 为 止 你 一 直 在 使 用 





日 你 能 够 用 一 个 外 部 的 2 























| 





























外 ， 你 还 能 用 一 个 图 形 化 的 工具 来 合并 和 解决 冲突 从 i 
来 做 比较 和 合并 工作 ， 它 就 是 P4Merge (译注 : Perforce 

P4Merge 可 以 在 所 有 主流 平台 上 运行 ， 现 在 开始 大 胆 尝试 吧 。 对 
我 会 使 用 路 径 名 ， 在 Windows 上，/usr/local/bin 应 该 被 改 为 你 环境 





















































| 
nM 



























































下 载 P4Merge: 


http://www.perforce.com/perforce/downloads/component.html 


首先 把 你 要 运行 的 命令 放 入 外 部 包装 脚本 中 ， 我 会 使 用 



























































决 。 有 一 个 不 错 上 














































































































上 的 路 径 来 指定 该 脚本 的 位 置 ， 在 









































E. 它 应 该 被 放置 在 二 进 制 文件 pamerge 所 在 的 目录 中 。 





















































数 调 用 p4merge 二 进 制 文件 : 














创建 一 个 merge 包 装 脚本 ， 名 字 叫 作 extMersge， 


Scott Chacon Pro Git 


4 他 的 参数 还 有 false 和 always，false 意 味 着 不 为 输 
或 管道 。Git 1.5.5 版 本 引 





! 插 入 颜色 码 ， 你 能 传递 -- 


TRA 


的 。 


正如 以 上 例 


CARE, BRILL 
[ 具 可 以 被 


展示 的 例子 ， 在 Mac 和 Linux 系 统 上 ， 
! 的 可 执行 路 径 。 


ILe 


LETZ 
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$ cat /usr/local/bin/extMerge 
#!/bin/sh 
/Applications/p4merge.app/Contents/MacOS/p4merge $* 







































































diff 包 装 脚 本 首先 确定 传递 过 来 7 个 参数 ， 随 后 把 其 中 2 个 传递 给 merge 包 装 脚本 ， 默 认 情 况 下 ， Git 传递 以 
下 参数 给 diff: 




















path old-file old-hex old-mode new-file new-hex new-mode 




















于 你 仅仅 需要 o1d-file 和 new-file 参 数 ， 用 diff 包 装 脚 本 来 传递 它们 1 

















[B 




















$ cat /usr/local/bin/extDiff 
#!/bin/sh 
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5" 























确认 这 两 个 脚本 是 可 执行 的 : 


$ sudo chmod +x /usr/local/bin/extMerge 
$ sudo chmod +x /usr/local/bin/extDiff 






























































现在 来 配置 使 用 你 自 定 义 的 比较 和 合 具 吧 。 这 需要 许多 自 定义 设置 merge.tool 通 知 Git 使 用 哪个 合 
工具 ; mergetool.*.cmd 规 定 命令 运 行 的 方式 ; mergetool.trustExitCode 会 通知 Git 程序 的 退出 是 否 指 示 合 并 操作 成 
Dj; diff.externaljH# Git 用 什么 命令 做 比较 。 因 此 ， 你 能 运行 以 下 4 条 配置 命令 : 






































































































































































































































$ git config --global merge.tool extMerge 

$ git config --global mergetool.extMerge.cmd V 
'extMerge "SBASE" "$LOCAL" "$REMOTE" "$MERGED" ' 

$ git config --global mergetool.trustExitCode false 

$ git config --global diff.external extDiff 











或 4 H 辑 -/.gitconfig 文 件 如 下 : 





























[merge 
tool = extMerge 

[mergetool "extMerge"] 
cmd = extMerge "$BASE" "$LOCAL" "SREMOTE" "$MERGED" 
trustExitCode = false 

[diff] 


external = extDiff 


设置 完毕 后 ， 运 行 diff 命 令 ， 
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$ git diff 32d1776b1”32d1776b1 





命令 行 居然 没有 发 现 diff 命 令 的 输出 ， 其 实 ，Git 调用 了 刚刚 设置 的 P4Merge， 它 看 起 来 像 图 7-1 这 样 : 











ido IN G9 92» Pa EH a 


"Refresh all (CR) ng differences) Tab spacing: 4 Encoding: System 
J XChuCDJRSHjSPlk-e4- TI /- Tmp- / / -diff CBASUP @ index.html 


CIDOCTTPE 上 PUBLIC "-//Ww3C//DCD XNTML 1.0 Striet//EN *IDOCTTPE htsl PUBLIC '-//W3C//DCD XHTML 1.0 Strict//EX 
chtml xmins*"httpi//www.wJ.org/1999/xhtazl'» <html xamins*"httpi //wwv.w).0rg/1999/xhtml'» 
<head> <head> 
<titleDate Finder</titie> <title>Date Finder«/titie» 
<meta http-equive'contest-type' contente'text/hts]; ¢ «seta http-equive'contest-type' contente'text/htsl; cj 
<link rel*"stylesheet' href*"/stylesheets/applicatic <link rel='stylesheet” href*"/stylesheets/applicaticn 
< javascript include tag ‘prototype’, 'effecta' > <0 javascript include tag ‘prototype’, 'effecta' Ww» 
</head> </head> 
<body> <body> 
Date Tisder Date Finder 
«form onsubait="return felee; “> <form onsubsit-'return false;"» 
«V^ text field tag('date') %> «1^ text field tag('date') è> 
C/form» «/form» 
tp idetogt 5... «/p» <p id-"out">..-</p> 
"div ag porer »piease contact us at supportfgaithub.co 


€script type*"text/javascript'» 








new Form.Element.Observer( <script type*'text/javascript'» 
"date", 
0.5, new Form.Element.Observer( 
fusetion(el, valoe){ ‘date’, 
new Ajax.Request('/main/chronic/" + value, { 0.5, 
method: 'get', fusetion(el, valve){ 
on$uccess: function(transport){ new Ajax.Request('/main/chronic/" + value, { 
$('out').innerü XL = tranasport.respocsecext; method: 'get', 
) onSuccess: function(transport) { 
n: $('o9t').innertü7XL = transport.respoasetext; 
} ) 
) n: 
} 
</ecript> ) ^ 
bod </script> Y 


jaiei Z 


图 7.1: P4Merge. 














当 你 设法 合并 两 个 分 支 ， 结 果 却 有 冲突 时 ， 运 行 git merzetool, Git 会 调用 P4Merge 让 你 通过 图 形 界面 来 解决 
冲突 。 

设置 包装 脚本 的 好 处 是 你 能 简单 地 改变 diff 和 merge 工 具 ， 例如 把 extpiff 和 和 extMerge 改 成 KDiff3， 要 做 的 仅仅 
是 编辑 extMerge 脚 本 文件 : 











$ cat /usr/local/bin/extMerge 
#!/bin/sh 
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $* 


现在 Git 会 使 用 KDiff3 来 做 比较 、 合 并 和 解决 冲突 。 

Git 预 先 设置 了 许多 其 他 的 合并 和 人 解决 冲突 的 工具 ， 而 你 不 必 设 置 cnd。 可 以 把 合并 工具 设置 为 : kd- 
iff3、opendiff、tkdiff、meld、xxdiff、emerge、vimdiff、gvimdiff。 如 果 你 不 想 用 到 KDiff3 的 所 有 功 
能 ， 只 是 想 用 它 来 合并 ， 那么 kdiff3 正 符合 你 的 要 求 ， 运 行 : 
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$ git config --global merge.tool kdiff3 























如 果 运 行 了 以 上 命令 ， 没 有 设置 
比较 。 


7.1.4 格式 化 与 空白 












































extMerge 利 extDiff 文 件 , Git 





A 
zB 

















KDiff3 做 合 
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， 让 通常 内 设 的 比较 工具 来 做 















































































































































































































































格式 化 与 空白 是 许多 开发 人 员 在 协作 时 ， 特 别 是 在 跨 平台 情况 下 ， 遇 到 的 令 人 头疼 的 细小 问题 。 由 于 编辑 
器 的 不 同 或 者 Windows 程 序 员 在 跨 平台 项 目 中 的 文件 行 尾 加 入 了 回 车 换行 符 ， 些 细微 的 空格 变化 会 不 经 意 地 
进入 大 家 合作 的 工作 或 提交 的 补丁 中 。 不 用 怕 ，Git 的 一 些 配置 选项 会 帮助 你 解决 这 些 问 题 。 
core.autocrlf 
假如 你 正在 Windows 上 写 程序 ， 又 或 者 你 正在 和 其 他 人 合作 ， 他 们 在 Windows 上 编程 ， 而 你 却 在 其 他 系统 上 ， 
在 这 些 情况 下 ， 你 可 能 会 遇 到 行 尾 结束 符 问 题 。 这 是 因为 Windows 使 用 回 车 和 换行 两 个 字符 来 结束 一 行 ， 而 
Mac 和 Linux 只 使 用 换行 一 个 字符 。 虽然 这 是 小 问题 ， 但 它 会 极 大 地 扰乱 跨 平台 协作 。 
Git 可 以 在 你 提交 时 自动 地 把 行 结束 符 CRLF 转 换 成 LE， 而 在 签 出 代码 时 把 LF 转换 成 CRLF。 用 core.autocr1f 来 打 
此 项 功能 ， 如 果 是 在 Windows 系 统 上 ， 把 它 设置 成 true， 这 样 当 签 出 代码 时 ，LEF 会 被 转换 成 CRLF: 
$ git config --global core.autocrlf true 
Linux 或 Mac 系 统 使 用 LF 作为 行 结束 符 ， 因 此 你 不 想 Git 在 签 出 文件 时 进行 自动 的 转换 ， 当 一 个 以 CRLF 为 行 
结束 符 的 文件 不 小 心 被 引入 时 你 肯定 想 进行 修正 ， 把 core.autocr1f 设 置 成 i 
换 成 LF， 





签 出 时 不 转换 ; 





$ git config --globa 























这 样 会 在 Windows 系 统 上 的 签 





如 果 你 是 Windows 程 序 员 ， 








H 
Li 
ni 


core.autocrlf input 























在 库 中 : 








EF 在 开发 仅 运行 在 Windows 上 的 项 目 


文件 中 保留 CRLF， 会 在 Mac 和 Linux 系 统 上 ， 


nput 来 告诉 Git 在 提交 时 把 CRLF 转 





























$ git config --global core.autocrlf false 


core.whitespace 
































Git 预 先 设置 了 一 些 选 项 来 探测 和 修正 空 





























自由 地 打开 或 关闭 它们 。 
默认 被 打开 
tab 会 查找 每 行 


里 
ny 



























































头 的 行 ， cr-at-eolit Git 知道 行 














EZH 





问题 ， 











多 2 个 选项 xe trail ing-space fll space-before-tab, trail ing-space 会 查找 每 


头 的 制 表 符 前 的 空格 。 
认 被 关闭 的 2 个 选项 是 indent-with-non-tab 和 cr-at-eol， indent-with-non-tab 会 查找 8 个 以 上 空格 (dE 
































尾 回 车 符 是 合法 的 。 























包括 仓库 1 











保留 LF © 














， 可 以 设置 false 取 消 此 功能 ， 把 回 车 符 记 录 





4 种 主要 选项 





























的 2 个 默认 被 打 


so 


TT 





























一 口 


， 男 2 个 被 关闭 ， 你 可 以 





结 E 的 空格 , Space-before- 
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表 符 ) 
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设置 core.whitespace， 按 照 你 的 意图 来 打开 或 关闭 选项 ， 选 项 以 逗号 分 割 。 通 过 逗号 分 割 的 链 中 去 掉 选 项 或 在 
选项 前 加 -来 关闭 ， 例 如 ， 如 果 你 想 要 打开 除了 cr-at-eol 之 外 的 所 有 选项 : 





















































$ git config --global core.whitespace \ 


trailing-space,space-before-tab,indent-with-non-tab 








M 


当 你 运行 sit diff 命 令 且 为 输出 着 色 时 ，Git 探测 到 这 些 问 题 ， 因 此 你 也 许 在 提交 前 能 修复 它们 ， 当 你 用 git 
apply 打 补丁 时 同样 也 会 从 中 受益 。 如 果 正 准备 运用 的 补丁 有 特别 的 空白 问题 ， 你 可 以 让 Git 发 警告 : 

















































































































$ git apply --whitespace=warn «patch» 





或 者 让 Git 在 打上 补丁 前 自动 修正 此 问题 : 














$ git apply --whitespace=fix «patch» 
































这 些 选 项 也 能 运用 于 衍 合 。 如 果 提 交 了 有 空白 问题 的 文件 但 还 没 推送 到 上 流 ， 你 可 以 运行 带 有 --whitespace=fix 选 
项 的 rebase 来 让 Git 在 重 写 补丁 时 自动 修正 它们 。 







































































7.1.5 服务 器 端 配置 

















Git 服 务 器 端的 配置 选项 并 不 多 ， 但 仍 有 一 些 馈 





an 
Dr 








E 趣 的 选项 值得 你 一 看 。 
































receive.fsckObjects 







































































Git 默 认 情 况 下 不 会 在 推送 期 间 检 查 所 有 对 象 的 一 致 性 。 虽 然 会 确认 每 个 对 象 的 有 效 性 以 及 是 否 仍 然 匹配 
SHA-1 检 验 和 ， 但 Git 不 会 在 每 次 推送 时 都 检查 一 致 性 。 对 于 Git 来 说 ， 库 或 推送 的 文件 越 大 ， 这 个 操作 代 
价 就 相对 越 高 ， 每 次 推送 会 消耗 更 多 时 间 ， 如 果 想 在 每 次 推送 时 Git 都 检查 一 致 性 ， 设 置 receive.fsckObjects 为 
true 来 强迫 它 这 么 做 : 










































































































































































$ git config --system receive.fsckObjects true 














现在 Git 会 在 每 次 推送 生效 前 检查 库 的 完整 性 ， 确 保有 问题 的 客户 端 没 有 引入 破坏 性 的 数据 。 









































receive.denyNonFastForwards 





































































































如 果 对 已 经 被 推送 的 提交 历史 做 衍 合 ， 继 而 再 推送 ， 又 或 者 以 其 它 方式 推送 一 个 提交 历史 至 远程 分 文 ， 且 该 
提交 历史 没 在 这 个 远程 分 支 中 ， 这 样 的 推送 会 被 拒绝 。 这 通常 是 个 很 好 的 禁止 策略 ， 但 有 时 你 在 做 衍 合 并 确定 
要 更 新 远程 分 文 ， 可 以 在 push 命 令 后 加 -f 标 志 来 强制 更 新 。 


要 禁用 这 样 的 强制 更 新 功能 ， 可 È 设置 receive. denyNonFastForwards: 












































































































































































































































$ git config --system receive.denyNonFastForwards true 
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7.27 Git 属 


[ES 
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TERCER SEU. HARB as MHF th RETA SI PEAY ELE] o 320777 TA n] MEC ZEB) dug], (RAD: 禁用 特 
定 的 用 户 做 强制 更 新 。 
receive.denyDeletes 

规避 denyNonFastForwards 策 略 的 方法 之 一 就 是 用 户 删除 分 支 ， 然 后 推 回 新 的 引用 。 在 更 新 的 Git 版 本 中 UA 


1.6.1 版 本 玫 


HT 


Ly 


PNE 



































receive. denyDeletes 设 置 为 true: 

















$ git config --system receive.denyDeletes true 

















































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































这 样 会 在 推送 过 程 中 阻止 删除 分 支 和 标签 一 没有 用 户 能 够 这 么 做 。 要 删除 远程 分 文 ， 必 须 从 服务 器 手动 删 
余 引 用 文件 。 通 过 用 户 访 问 控制 列表 也 能 这 么 做 ， 在 本 章 结尾 将 会 介绍 这 些 有 趣 的 方式 。 
7.2 Git 属 性 

此 设置 项 也 能 被 运用 于 特定 的 路 径 中 ， 这 样 ，Git 以 对 一 个 特定 的 子 目录 或 子 文件 集运 用 那些 设置 项 。 这 

些 设置 项 被 称 为 Git 属性 ， 可 以 在 你 目录 中 的 .sitattributes 文 件 内 进行 设置 (通常 是 你 项 目的 根 目录 ) ， 也 
可 以 当 你 不 想 让 这 些 属性 文件 和 项 目 文件 一 同 提 交 时 ， 在 .git/info/attributes 进 行 设置 。 

使 用 属性 ， 你 可 以 对 个 别 文 件 或 目录 定义 不 同 的 合并 策略 ， 让 Git 知道 怎样 比较 非 文 本 文件 ， 在 你 提交 或 
签 出 前 让 Git 过 滤 内 容 。 你 将 在 这 部 分 了 解 到 能 在 自己 的 项 目 中 使 用 的 属性 ， 以 及 一 些 实例 。 
7.2.1 二 进 制 文件 

你 可 以 用 Git 属性 让 其 知道 哪些 是 二 进 制 文件 (以 防 Git 没有 识别 出 来 ) ， 以 及 指示 怎样 处 理 这 些 文件 ， 
这 点 很 酷 。 例 如 ， 一 些 文本 文件 是 由 机 器 产生 的 ， 而 且 无 法 比较 ， 而 一 些 二 进 制 文件 可 以 比较 一 你 将 会 了 解 
到 怎样 让 Git 识别 这 些 文件 。 
识别 二 进 制 文件 

一 些 文件 看 起 来 像 是 文本 文件 ， 但 其 实 是 作为 二 进 制 数据 被 对 待 。 例 如 ， 在 Mac 上 的 Xcode 项 目 含 有 一 个 
以 .pbxproj 结 尾 的 文件 ， 它 是 由 记录 设置 项 的 IDE 写 到 磁盘 的 JSON 数 据 集 〈 纯 文本 javascript 数 据 类 型 ) 。 虽 然 
技术 上 看 它 是 由 ASCII 字 符 组 成 的 文本 文件 ， 但 你 并 不 认为 如 此 ， 因 为 它 确实 是 一 个 轻 量 级 数据 库 一 如 果 有 2 
人 改变 了 它 ， 你 通常 无 法 合并 和 比较 内 容 ， 只 有 机 器 才能 进行 识别 和 操作 ， 于 是 ， 你 想 把 它 当 成 二 进 制 文件 。 

让 Git 把 所 有 pbxproj 文 件 当 成 二 进 制 文件 ， 在 .gitattributes 文 件 ! 设置 如 下 
*.pbxproj -crlf -diff 

现在 ，Git 会 党 试 转换 和 修正 CRLF ( 回 车 换行 ) 问题 ， 也 不 会 当 你 在 项 目 中 运行 git show 或 git diff 时 ， 比 
较 不 同 的 内 容 。 在 Git 1.6 及 之 后 的 版 本 中 ， 可 以 用 一 个 宏 代替 -cr1f -diff: 





* pbxproj binary 
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比较 二 进 制 文件 







































































成 文本 格式 ， 用 通常 的 diff 来 比较 。 



































在 Git 1.6 及 以 上 版 本 中 ， 你 能 利用 Git 属性 来 有 效 地 比较 二 进 制 文件 。 可 以 设置 Git Fi 
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二 进 制 数据 转换 














这 个 特性 很 酷 ， 而 且 鲜 为 人 知 ， 因 此 我 会 结合 实例 来 讲解 。 首 先 ， 要 解决 的 是 最 令 人 头疼 的 问题 : 对 Word 文 



















































































档 进 行 版 本 控制 。 Ce 如 果 想 对 其 进行 版 本 控制 ， 你 可 以 把 文 伯 
每 次 修改 后 提交 即 可 。 但 这 样 做 没有 一 点 实际 意义 ， 因 为 运行 fit diff 命 令 后 ， 你 只 







































































$ git diff 

diff --git a/chapterl.doc b/chapterl.doc 

index 88839c4..4afcb7c 100644 

Binary files a/chapterl.doc and b/chapterl.doc differ 






































你 不 能 直接 比较 两 个 不 同 版 本 的 Word 文 件 ， 除 非 进行 手动 扫描 ， 不 是 吗 ? Git 
把 MI 的 行 加 到 .sgitattributes 文 件 : 


















































*.doc diff=word 



















































































F 加 入 到 Git 库 中 ， 























能 得 到 如 下 的 结果 : 











38] 

















T 


















































实 就 是 Git 使 用 strings 程序 ， 把 Word 文 档 转换 成 可 读 的 文本 文人 


$ git config diff.word.textconv strings 



































现在 如 果 在 两 个 快照 之 间 比 较 以 .doc 结 尾 的 文件 ，Git 对 这 些 文件 运用 “word” 
件 转 换 成 文本 文件 。 










































































生 能 很 好 地 解决 此 问题 ， 


当 你 要 看 比较 结果 时 ， 如 果 文 件 扩展 名 是 “doc”，Git 调用 “word” 过 滤器 。 什 么 是 “word” 过 滤器 呢 ? 
之 后 再 进行 比较 : 


过 滤器 ， 在 比较 前 把 Word 文 

















下 面 展示 了 一 个 实例 ， 我 把 此 书 的 第 一 章 纳入 Git 管理 ， 在 一 个 段落 中 加 入 了 一 些 文本 后 保存 ， 之 后 运 















































行 git diff 命 令 ， 得 到 结果 如 下 : 








$ git diff 

diff --git a/chapterl.doc b/chapterl.doc 

index clc8a0a..b93c9e4 100644 

--- a/chapterl.doc 

+++ b/chapterl.doc 

@@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics 
re going to cover how to get it and set it up for the first time if you don 
t already have it on your system. 
In Chapter Two we will go over basic Git usage - how to use Git for the 80% 
-s going on, modify stuff and contribute changes. If the book spontaneously 
*s going on, modify stuff and contribute changes. If the book spontaneously 


*Let's see if this works. 
































Git 成 功 且 简洁 地 显示 出 我 增加 的 文本 “Let”s see if this works" ° B&A 

















RE, di 














PA 尾 显 示 J 些 





































































































随机 的 内 容 ， 但 确实 可 以 比较 了 。 如 果 你 能 找到 或 自己 写 个 Word 到 纯 文本 的 转换 器 的 话 ， 效 果 可 能 会 更 好 。 






























































strings A] 以 在 大 部 分 Mac 和 Linux 系 统 上 运行 ， 所 以 它 是 处 到 长 一 全 进 制 格 式 的 第 一 选择 











H 


164 








o 


Scott Chacon Pro Git 














你 还 能 用 这 个 方法 比较 图 











































































































7.2 节 Git 属 性 

















像 文件 。 当 比较 时 ， 对 JPEG 文 件 运 用 一 个 过 滤器 ， 它 能 提炼 出 EXIF 信 息 一 大 部 分 









































$ echo '*.png diff=exif' >> .gitattributes 


$ git config diff.exif.textconv exiftool 























如 果 在 项 目 中 替换 了 一 个 











diff --git a/image.png b/image 
index 88839c4. .4afcb7c 100644 
--- a/image.png 

+++ b/image.png 

@@ -1,12 +1,12 ao 

ExifTool Version Number 
-File Size 

-File Modification Date/Time 
*File Size 

+File Modification Date/Time 
File Type 

MIME Type 

-Image Width 

-Image Height 

*Image Width 

*Image Height 

Bit Depth 

Color Type 








图 像 格式 使 用 的 元 数据 。 如 果 你 下 载 并 安装 了 exiftool 程 序 ， 可 以 用 它 参 
不 同 结果 将 会 用 文本 向 你 展示 : 





























.png 


e "mma: 

: 70 kB 

: 2009:04:21 07:02:45-07:00 
: 94 kB 

: 2009:04:21 07:02:43-07:00 
: PNG 

: image/png 

: 1058 

: 889 

: 1056 

: 827 

: 8 

: RGB with Alpha 


你 会 发 现 文件 的 尺寸 大 小 发 生 了 改变 。 





7.2.2 关键 字 扩 展 



































会 完 对 该 文件 计算 校 验 和 。 然 而 ， 你 可 以 在 签 出 时 注入 文本 ， 在 提交 前 用 








做 。 
























































本 身 的 校 验 和 |: 


先 ， 你 能 够 把 blob 的 SHA-1 校 验 和 自动 注入 文 伯 
REE SP SCAR, Git 用 blob 的 SHA-1 值 替换 那个 字段 。 六 














图 像 文件 ， 运 行 sit diff 命 令 的 结果 如 下 : 





照 元 数据 把 图 像 转换 成 文本 。 比 较 的 














使 用 SVN 或 CVS 的 开发 人 员 经 常 要 求 关键 字 扩展 。 在 Git 中 ， 你 无 法 在 一 个 文件 被 提交 后 修改 它 ， 因 为 Git 
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的 SIds 字 段 。 如 果 在 











IRE ° Git 属性 提供 了 2 种 方式 这 么 


— 


























个 或 多 个 文件 上 设置 了 此 字段 ， 当 















































FE 意 ， 这 不 是 提交 对 象 的 SHA 校 验 和 ， 而 是 blob 























$ echo '*.txt ident' >> .gitattributes 


$ echo '$Id$' > test.txt 





下 次 签 出 文件 时 ，Git 入 了 blob 的 SHA 人 
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$ rm text.txt 

$ git checkout -- text.txt 

$ cat test.txt 

$Id: 42812b7653c7b88933f8a9d6cad0cal6714b9bb3 $ 















































然而 ， 这 样 的 显示 结果 没有 多 大 的 实际 意义 。 这 个 SHA 的 值 相当 地 随机 ， 无 法 区 分 日 期 的 前 后 ， 所 以 ， 如 果 
你 在 CVS 或 Subversion 中 用 过 关键 字 替 换 ， 一 定 会 包含 一 个 日 期 值 。 

因此 ， 你 能 写 自 己 的 过 滤器 ， 在 提交 文件 到 和 暂 存 区 或 签 出 文件 时 替换 关键 字 。 有 2 种 过 滤器 ，“clean” 和 “smudge ”。 
在 .sgitattributes 文 件 中 ， 你 能 对 特定 的 路 径 设置 一 个 过 滤器 ， 然 后 设置 处 理 文件 的 脚本 ， 这 些 脚本 会 在 文件 签 
出 前 ( “smudge” , WA 7.2) 和 提交 到 暂 存 区 前 (“clean”， 见 图 7-3) 被 调用 。 这 些 过 滤器 能 够 做 各 种 有 
趣 的 事 。 



























































































































































Staging Area Working Directory 


[ome | 








git checkout 


图 7.2: 签 出 时 ，“smudge” 过 滤器 被 触发 。 


Staging Area Working Directory 





git add 


图 7.3: 提交 到 暂 存 区 时 ，“clean” 过 滤器 被 触发 。 


























这 里 举 一 个 简单 的 例子 : 在 暂 存 前 ， 用 indent ( 缩 进 ) 程序 过 滤 所 有 C 源 代码 。 在 .gitattributes 文 件 中 设 
置 “indent” 过 滤器 过 滤 *.c 文 件 : 




















EC filter-indent 





然后 ， 通 过 以 下 配置 ， 让 Git 知道 “indent” 过 滤器 在 遇 到 “smudge” 和 “clean” 时 分 别 该 做 什么 : 
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$ git config --global filter.indent.clean indent 
$ git config --global filter.indent.smudge cat 

























































































































































































于 是 ， 当 你 暂 存 *.c 文 件 时 ，indent 程 序 会 被 触发 ， 在 把 它们 签 出 之 前 ，cat 程 序 会 被 触发 。 但 cat 程 序 在 这 里 没 
什么 实际 作用 。 这 样 的 组 合 ， 使 源 代码 在 暂 存 前 被 indent 程 序 过 滤 ， 非 常 有 效 。 

另 一 个 例子 是 类 似 RCS 的 Spate$ 关 键 字 扩展 。 为 了 演示 ， 需 要 一 个 小 脚本 ， 接 受 文件 名 参数 ， 得 到 项 目的 最 新 
提交 日 期 ， 最 后 把 日 期 写 入 该 文件 。 下 面 用 Ruby 脚 本 来 实现 : 






































#! /usr/bin/env ruby 

data - STDIN.read 

last date = ‘git log --pretty-format: ad" -1` 

puts data.gsub('$Date$', '$Date: ' + last date.to s + '$') 
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n 














该 脚本 从 git 1og 命 令 中 得 到 最 新 提交 日 期 ， 找 到 文件 中 的 所 有 $Dates 字 符 串 ， 最 后 把 该 日 期 填充 到 spates 字 符 
中 一 此 脚本 很 简单 ， 你 可 以 选择 你 喜欢 的 编程 语言 来 实现 。 把 该 脚本 命名 为 espand_date， 放 到 正确 的 路 径 
中 ， 之 后 需要 在 Git 设置 个 过 滤器 (dater) A 让 它 在 签 出 文件 时 调用 expand date, 在 ETE X EB ]Per1JÉ 
除 之 : 
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$ git config filter.dater.smudge expand date 
$ git config filter.dater.clean ‘perl -pe "s/\\\$Date[*\\\$]*\\\$/\\\$Date\\\$/"' 

















Perl EES espaces SH REER BE AGAR USER, KEAN ^ SIE BIDS IE, MARE Ie BS 
毕 ， 可 以 开始 测 斌 了。 打开 一 个 文件 ， 在 文件 中 输入 spates 关 键 字 ， 然 后 设置 Git 属性 : 
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$ echo '# $Date$' > date test.txt 
$ echo 'date*.txt filter-dater' >> .gitattributes 























如 果 暂 存 该 文件 ， 之 后 再 签 出 ， 你 会 发 现 关键 字 被 奉 换 了 : 





























git add date test.txt .gitattributes 

git commit -m "Testing date expansion in Git" 
rm date test.txt 

git checkout date test.txt 

cat date test.txt 

$Date: Tue Apr 21 07:26:52 2009 -0700$ 


b 09 09 09 HF HF 


















































虽说 这 项 技术 对 自 定 义 应 用 来 说 很 有 用 ， 但 还 是 要 小 心 ， 因 为 .gitattributes 文 件 会 随 着 项 目 一 起 提交 ， 而 过 
滤器 (例如 : dater) AB, ATLA, 过 滤器 不 会 在 所 有 地 方 都 生效 。 当 你 在 设计 这 文 些 过 滤器 时 要 注意 ， 即 使 它们 
无 法 正常 工作 ， 也 要 让 整个 项 目 运 作 下 去 。 

















um 





































































































7.2.3 导出 仓库 
Git 属 性 在 导出 项 目 归档 时 也 能 发 挥 作 用 。 
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export-ignore 


























TF 











当 产 生 一 个 归档 时 ， 可 以 设置 Git 不 导出 某 些 文件 和 目录 。 如 果 你 不 想 在 归档 中 包含 一 个 子 目录 或 文件 
但 想 他 们 纳入 项 目的 版 本 管理 中 ， 你 能 对 应 地 设置 export-ignore 属 性 。 
例如 ， 在 test/ 子 目录 中 有 一 些 测试 文件 ， 在 项 目的 压缩 包 中 包含 他 们 是 没有 意义 的 。 因 此 ， 可 以 增加 下 面 这 


录 
行 到 Git 属性 文件 中 : 















































































































































































































































test/ export-ignore 






























































现在 ， 当 运行 git archive 来 创建 项 目的 压缩 包 时 ， 那 个 目录 不 会 在 归档 中 出 现 。 











export-subst 


























XR BENT VEA fL — EE 18] LE BES Ao FEO EAA DUE SI, nT BLEL--prettysformatJÉ & HJ fal FS CE EAA C 
F 中 放 入 $Format:$ 字符 串 。 例 如 ， 如 果 想 在 项 目 中 包含 一 个 叫 作 LAST_coMMIT 的 文件 ， 当 运行 git archive 时 ， 最 后 
提交 日 期 自动 地 注入 进 该 文件 ， 可 以 这 样 设置 : 
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echo 'Last commit date: $Format:%cd$' > LAST COMMIT 
echo "LAST COMMIT export-subst" >> .gitattributes 
git add LAST COMMIT .gitattributes 

git commit -am 'adding LAST COMMIT file for archives' 




















运行 git archive 后 ， 打开 该 文件 ， 会 发 现 LA AU h: 





























$ cat LAST COMMIT 
Last commit date: $Format:Tue Apr 21 08:38:48 2009 -0700$ 


















































通过 Git 属性 ， 还 能 对 项 目 中 的 特定 文件 使 用 不 同 的 合并 策略 。 一 个 非常 有 用 的 选项 就 是 ， 当 一 些 特定 文 
件 发 生 冲 突 ，Git 会 尝试 合并 他 们 ， 而 使 用 你 这 边 的 合并 。 

如 果 项 目的 一 个 分 支 有 卜 义 或 比较 特别 ,但 你 想 从 该 分 支 合并 ， 而 且 需 要 忽略 其 中 某 些 文 件 ， 这 样 的 合并 策 
略 是 有 用 的 。 例 如 ， 你 有 一 个 数据 库 设 置 文件 database,xml1， 在 2 个 分 文中 他 们 是 不 同 的 ， 你 想 合 并 一 个 分 支 
到 男 一 个 ， 而 不 弄 乱 该 数据 库 文 件 ， 可 以 设置 属性 如 下 : 


































































































































































































y 










































































mi 





























database.xml merge-ours 















































如 果 合 并 到 另 一 个 分 文 ，database ,xml 文件 不 会 有 合并 冲突 ， 显 示 如 下 : 
































$ git merge topic 
Auto-merging database.xml 


Merge made by recursive. 


这 样 ，database . xml 会 保持 原样 o 
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和 其 他 版 本 控制 系统 一 样 ， 当 某 些 重要 事件 发 生 时 ，Git 以 调用 自 定义 脚本 。 有 两 组 挂钩 : 客户 端 和 服务 器 
端 。 客 户 端 挂 钩 用 于 窗户 端的 操作 ， 如 提交 和 合并 。 服 务 器 端 挂 钧 用 于 Git 服务 器 端的 操作 ， 如 接收 被 推送 
的 提交 。 你 可 以 随意 地 使 用 这 些 挂 钩 ， 下 面 会 讲解 其 中 一 些 。 








na 





















































































































































7.38.1 XX —^MESS 


挂钩 都 被 存储 在 Git 目录 下 的 hooks 子 目录 中 ， 即 大 部 分 项 目 中 的 .sit/nooks。 Git 默认 会 放置 一 些 脚本 样本 
在 这 个 目录 中 ， 除 了 可 以 作为 持 钢 使 用 ， 这 些 样本 本 身 是 可 以 独立 使 用 的 。 所 有 的 样本 都 是 she11 脚 本 ， 其 中 
一 些 还 包含 了 Per1 的 脚本 ， 不 过 ， 任 何 正确 命名 的 可 执行 脚本 都 可 以 正常 使 用 一 可 以 用 Ruby 或 Python， 或 其 
他 。 在 Git 1.6 版 本 之 后 ， 这 些 样本 名 都 是 以 .sample 结 必 ， 因 此 ， 你 必须 重新 命名 。 在 Git 1.6 版 本 之 前 ， 这 
样本 名 都 是 正确 的 ， 但 这 些 样 本 不 是 可 执行 文件 。 
把 一 个 正确 命名 且 可 执行 的 文件 放 入 Git 目录 下 的 nooks 子 目录 中 ， 可 以 激活 该 挂 钧 脚本 ， 因 此 ， 之 后 他 一 
会 被 cic 调用 。 随 后 会 讲解 主要 的 桂 多 脚本 。 


































































































































































































































































































































































































































































































7.3.2 客户 端 挂钩 
有 许 户 端 挂 钩 ， 以 下 把 他 们 分 为 : 提交 工作 流 挂钩、 电子 邮件 工作 流 挂钩 及 其 他 客户 端 挂 钩 。 
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有 4 个 挂钩 被 用 来 处 理 提 交 的 过 程 。pre-commit 挂 钩 在 键入 提交 信息 前 运行 ， 被 用 来 检查 即将 提交 的 快照 ， 例 
0， 检查 是 否 有 东西 被 遗漏 ， 确 认 测 试 是 否 运 行 ， 以 及 检查 代码 。 当 从 该 挂 钧 返回 非 零 值 时 ，Git 放弃 此 次 提 
交 ， 但 可 以 用 git commit --no-verify 来 忽略 。 该 挂钩 可 以 被 用 来 检查 代码 错误 (运行 类 似 1int 的 程序 ) ， 检 查 尾 
部 空白 《默认 挂 钩 是 这 么 做 的 ) ， 检 查 新 方法 (译注 ， 程序 的 函数 ) 的 说 明 e 
prepare-comit-msg 挂 钩 在 提交 信息 编辑 器 显示 之 前 ， 默 认 信息 被 创建 之 后 运行 。 因 此 ， 可 以 有 机 会 在 提交 作 
者 看 到 默认 信息 前 进行 编辑 。 该 挂钩 接收 一 些 选项 : 拥有 提交 信息 的 文件 路 径 ， 提 交 类 型 ， 如 果 有 是 一 次 修订 的 
话 ， 提 交 的 SHA-1 校 验 和 。 该 挂钩 对 通常 的 提交 来 说 不 是 很 有 用 ， 只 在 自动 产生 的 默认 提交 信息 的 情况 下 有 作 
 ， 如 提交 信息 模板 、 合 并 、 压 缩 和 修订 提交 等 。 可 以 和 提交 模板 配合 使 用 ， 以 编程 的 方式 插入 信息 。 
commit-msg 挂 钩 接收 一 个 参数 ， 此 参数 是 包含 最 近 提 交 信 息 的 临时 文件 的 路 径 。 如 果 该 挂钩 脚本 以 非 零 退 
HH, Git 放弃 提交 ， 因 此 ， 可 以 用 来 在 提交 通过 前 验证 项 目 状 态 或 提交 信息 。 本 章 上 一 小 节 已 经 展示 了 使 用 该 
挂钩 核对 提交 信息 是 否 符合 特定 的 模式 。 
post-commit 挂 钩 在 整个 提交 过 程 完 成 后 运行 ， 他 不 会 接收 任何 参数 ， 但 可 以 运行 sit log -1 HEAp 来 获得 最 后 的 
提交 信息 。 总 之 ， 该 挂钩 是 作为 通知 之 类 使 用 的 。 
提交 工作 流 的 客户 端 挂钩 脚本 可 以 在 任何 工作 流 中 使 用 ， 他 们 经 常 被 用 来 实施 某 些 策略 ， 但 值得 
这 些 脚本 在 clone 期 间 不 会 被 传送 。 可 以 在 服务 器 端 实施 策略 来 拒绝 不 符合 某 些 策略 的 推送 ， 但 这 完全 取决 于 
发 者 在 客户 端 使 用 这 些 脚本 的 情况 。 所 以 ， 这 些 脚本 对 开发 者 是 有 用 的 ， 由 他 们 自己 设置 和 维护 ， 而 且 在 任 
何 时 候 都 可 以 覆盖 或 修改 这 些 脚 本 。 
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E-mail 工 作 流 挂 钧 



































有 3 个 可 用 的 客户 端 挂钩 用 于 e-mail 工 作 流 。 当 运行 git an 命令 时 ， 会 调用 人 他们， 因此， 如 果 你 没有 在 工作 
到 此 命令 ， 可 以 跳 过 本 节 。 如 果 你 通过 e-mail 接收 由 git format-patch 产 生 的 补丁 ， 这 些 挂钩 也 许 对 你 有 

























































































el 




































































先 运行 的 是 applypatch-msg 挂 钧 ， 他 接收 一 个 参数 : 包含 被 建议 提交 信息 的 临时 文件 名 。 如 果 该 脚本 非 零 退 
Hi, Git 放弃 此 补丁 。 可 以 使 用 这 个 脚本 确认 提交 信息 是 否 被 正确 格式 化 ， 或 让 脚本 编辑 信息 以 达到 标准 化 。 
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I 
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地 


























下 一 个 在 git an 运行 期 间 调用 是 pre-applypatch 挂 钧 。 该 挂钩 不 接收 参数 ， 在 补丁 被 运用 之 后 运行 ， 因 此 ， 可 以 
被 用 来 在 提交 前 检查 快照 。 你 能 用 此 脚本 运行 测试 ， 检 查 工 作 树 。 如 果 有 些 什么 遗漏 ， 或 测试 没 通过 ， 脚 本 会 
以 非 零 退 出 ， 放 弃 此 次 git an 的 运行 ， 补 丁 不 会 被 提交 。 

最 后 在 git an 运行 期 间 调 用 的 是 post-applypatch 挂 钩 。 你 可 以 用 他 来 通知 一 个 小 组 或 获取 的 补丁 的 作者 ， 但 无 
法 阻止 打 补丁 的 过 程 。 

































































































































































































































































其 他 客户 端 挂钩 
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pre- rebase fE TA TET] Gr BIS 11, MAN ERR h AY CAI AT AAS o Ven] MEANE ARRENE CLR 
推送 的 提交 对 象 ，Git pre- rebase 挂 钩 样本 就 是 这 么 做 的 。 该 样本 假定 next 是 你 定义 的 分 支 名 ， 因 此 ， 你 可 能 
要 修改 样本 ， 把 next 改 成 你 定义 过 且 稳 定 的 分 支 名 。 
在 git checkout 成 功 运行 后 ，post-checkout 挂 钩 会 被 调用 。 他 可 以 用 来 为 你 的 项 目 环境 设置 合适 的 工作 目录 。 例 
A: 放 入 大 的 二 进 制 文件 、 上 自动 产生 的 文档 或 其 他 一 切 你 不 想 纳入 版 本 控制 的 文件 。 

最 后 ， 在 merge 命 令 成 功 执行 后 ，post-nmerge 挂 钩 会 被 调用 。 他 可 以 用 来 在 Git 无 法 跟踪 的 工作 树 中 恢复 数 
据 ， 诸 如 权限 数据 。 该 挂钩 同样 能 够 验证 在 Git 控制 之 外 的 文件 是 否 存在 ， 因 此 ， 当 工作 树 改变 时 ， 你 想 这 
些 文件 可 以 被 复制 。 
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7.3.3 服务 器 端 挂钩 


























除了 客户 端 挂钩 ， 作 为 系统 管理 员 ， 你 还 可 两 个 服务 器 端的 挂钩 对 项 目 实施 各 种 类 型 的 策略 。 这 些 挂 
钩 脚 本 可 以 在 提交 对 象 推送 到 服务 器 前 被 调用 ， 也 可 以 在 推送 到 服务 器 后 被 调用 。 推 送 到 服务 器 前 调用 的 挂钩 
可 以 在 任何 时 候 以 非 零 退 出 ， 拒 绝 推 送 ， 返 回 错误 消息 给 客户 端 ， 还 可 以 如 你 所 愿 设 置 足够 复杂 的 推送 策略 。 
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pre-receive 和 post-receive 


The first script to run when handling a push from a client is pre-receive. It takes a list of 
references that are being pushed from stdin; if it exits non-zero, none of them are accepted. You 
can use this hook to do things like make sure none of the updated references are non-fast-forwards; 
or to check that the user doing the pushing has create, delete, or push access or access to push 
updates to all the files they' re modifying with the push. 

The post-receive hook runs after the entire process is completed and can be used to update other 
services or notify users. It takes the same stdin data as the pre-receive hook. Examples include 
e-mailing a list, notifying a continuous integration server, or updating a ticket-tracking system 
— you can even parse the commit messages to see if any tickets need to be opened, modified, or 
closed. This script can' t stop the push process, but the client doesn' t disconnect until it has 


completed; so, be careful when you try to do anything that may take a long time. 


update 


The update script is very similar to the pre-receive script, except that it' s run once for each 
branch the pusher is trying to update. If the pusher is trying to push to multiple branches, pre- 
receive runs only once, whereas update runs once per branch they' re pushing to. Instead of reading 
from stdin, this script takes three arguments: the name of the reference (branch), the SHA-1 that 
reference pointed to before the push, and the SHA-1 the user is trying to push. If the update 


Script exits non-zero, only that reference is rejected; other references can still be updated. 
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7.4 An Example Git-Enforced Policy 


In this section, you' 11 use what you' ve learned to establish a Git workflow that checks for a 
custom commit message format, enforces fast-forward-only pushes, and allows only certain users to 
modify certain subdirectories in a project. You' 11 build client scripts that help the developer 
know if their push will be rejected and server scripts that actually enforce the policies. 

I used Ruby to write these, both because it' s my preferred scripting language and because I 
feel it' s the most pseudocode-looking of the scripting languages: thus you should be able to 
roughly follow the code even if you don’ t use Ruby. However, any language will work fine. All 


the sample hook scripts distributed with Git are in either Perl or Bash scripting, so you can also 





see plenty of examples of hooks in those languages by looking at the samples. 


7.4.1 Server-Side Hook 


All the server-side work will go into the update file in your hooks directory. The update file 
runs once per branch being pushed and takes the reference being pushed to, the old revision where 
that branch was, and the new revision being pushed. You also have access to the user doing the 
pushing if the push is being run over SSH. If you’ ve allowed everyone to connect with a single 
user (like “git” ) via public-key authentication, you may have to give that user a shell wrapper 
that determines which user is connecting based on the public key, and set an environment variable 
specifying that user. Here I assume the connecting user is in the $USER environment variable, so 


your update script begins by gathering all the information you need: 


#!/usr/bin/env ruby 


$refname = ARGV[O] 
$oldrev = ARGV[1] 
$newrev = ARGV[2] 
$user = ENV[ 'USER' | 


puts "Enforcing Policies... \n(#{$refname}) (Z(Soldrev[0,6])) (Z(S$newrev[0,6]))" 


Yes, I’ m using global variables. Don’ t judge me 一 it’ s easier to demonstrate in this manner. 


Enforcing a Specific Commit-Message Format 


Your first challenge is to enforce that each commit message must adhere to a particular format. 
Just to have a target, assume that each message has to include a string that looks like “ref: 
1234” because you want each commit to link to a work item in your ticketing system. You must 
look at each commit being pushed up, see if that string is in the commit message, and, if the 
string is absent from any of the commits, exit non-zero so the push is rejected. 

You can get a list of the SHA-1 values of all the commits that are being pushed by taking the 
$newrev and $oldrev values and passing them to a Git plumbing command called git rev-list. This is 
basically the git 1og command, but by default it prints out only the SHA-1 values and no other 
information. So, to get a list of all the commit SHAs introduced between one commit SHA and 


another, you can run something like this: 
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$ git rev-list 538c33..dl4fc7 

d14£c7c847ab946ec39590d87783c69b031bdfb7 
9£585da4401b0a3999e84113824d15245c13f0be 
234071albe950e2a8d078e6141f5cd20c1e61ad3 
dfa04c9ef345197182f£13fb5b9b1fb7717d2222a 
17716ecOflff5c7TeffA0b7fe912f9f6cfd0e475 


You can take that output, loop through each of those commit SHAs, grab the message for it, and 
test that message against a regular expression that looks for a pattern. 

You have to figure out how to get the commit message from each of these commits to test. To get 
the raw commit data, you can use another plumbing command called git cat-file. I’ 11 go over all 


these plumbing commands in detail in Chapter 9: but for now, here' s what that command gives you: 


$ git cat-file commit ca82a6 

tree cfda3bf379e4f8dba87177dee55aab'78aef'7fAdaf 

parent 085bb3bcb608ele8451d4b2432f8ecbe6306e7e7 

author Scott Chacon <schacon@gmail.com> 1205815931 -0700 
committer Scott Chacon <schacon@gmail.com> 1240030591 -0700 


changed the version number 


A simple way to get the commit message from a commit when you have the SHA-1 value is to go to 
the first blank line and take everything after that. You can do so with the sed command on Unix 


systems: 


$ git cat-file commit ca82a6 | sed '1,/^$/d' 


changed the version number 


You can use that incantation to grab the commit message from each commit that is trying to be 
pushed and exit if you see anything that doesn' t match. To exit the script and reject the push, 


exit non-zero. The whole method looks like this: 


$regex = /\[ref: (\d+)\]/ 


# enforced custom commit message format 
def check message format 
missed revs = ‘git rev-list #{$oldrev}..#{$newrev}*.split("\n") 
missed revs.each do |rev| 
message = ‘git cat-file commit #{rev} | sed '1,/^$/d'^ 
if !$regex.match(message) 
puts "[POLICY] Your message is not formatted correctly" 
exity | 
end 
end 
end 


check_message_format 
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Putting that in your update script will reject updates that contain commits that have messages 


that don' t adhere to your rule. 


Enforcing a User-Based ACL System 


Suppose you want to add a mechanism that uses an access control list (ACL) that specifies which 
users are allowed to push changes to which parts of your projects. Some people have full access, 
and others only have access to push changes to certain subdirectories or specific files. To 
enforce this, you' 11 write those rules to a file named aci that lives in your bare Git repository 
on the server. You' 11 have the update hook look at those rules, see what files are being introduced 
for all the commits being pushed, and determine whether the user doing the push has access to 
update all those files. 

The first thing you’ 11 do is write your ACL. Here you’ 11 use a format very much like the CVS 
ACL mechanism: it uses a series of lines, where the first field is avail Or unavail, the next field 
is a comma-delimited list of the users to which the rule applies, and the last field is the path 
to which the rule applies (blank meaning open access). All of these fields are delimited by a 
pipe (|) character. 

In this case, you have a couple of administrators, some documentation writers with access to 
the doc directory, and one developer who only has access to the lib and tests directories, and your 


ACL file looks like this: 


avail|nickh,pjhyett,defunkt,tpw 
avail|usinclair,cdickens,ebronte|doc 


avail|schacon|1lib 





avail|schacon|tests 


You begin by reading this data into a structure that you can use. In this case, to keep the 
example simple, you’ 11 only enforce the avail directives. Here is a method that gives you an 
associative array where the key is the user name and the value is an array of paths to which the 


user has write access: 


def get acl access data(acl file) 
# read in ACL data 
acl file = File.read(acl file).split("Nn").reject { |line| line == '' ) 





access - () 
acl file.each do |1ine| 
avail, users, path = line.split('|') 
next unless avail -- 'avail' 
users.split(',').each do |user| 
access[user] ||= [] 
access[user] << path 
end 
end 
access 


end 


On the ACL file you looked at earlier, this get acl access data method returns a data structure 


that looks like this: 
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{"defunkt"=>[nil], 
"tpw"=>[nil], 
"nickh"=>[nil], 
"pjhyett"-»[nil], 
"schacon"=>["lib", "tests"], 
"cdickens"=>["doc" |, 
"usinclair"=>["doc"], 


"ebronte"=>[ "doc" |} 


Now that you have the permissions sorted out, you need to determine what paths the commits being 
pushed have modified, so you can make sure the user who’ s pushing has access to all of them. 
You can pretty easily see what files have been modified in a single commit with the --name-only 


option to the git log command (mentioned briefly in Chapter 2): 


$ git log -1 --name-only --pretty-format:'' 9f585d 


README 
lib/test.rb 


If you use the ACL structure returned from the get_acl_access_data method and check it against the 
listed files in each of the commits, you can determine whether the user has access to push all of 


their commits: 


# only allows certain users to modify certain subdirectories in a project 
def check_directory_perms 


access = get acl access data('acl') 


# see if anyone is trying to push something they can't 
new commits = ‘git rev-list #{$oldrev}..#{$newrev}*.split("\n") 
new_commits.each do |rev| 
files modified = ‘git log -1 --name-only --pretty-format:'' #{rev}*.split("\n") 
files_modified.each do |path| 
next if path.size -- 0 
has file access - false 
access|$user]|.each do access path| 
if laccess path # user has access to everything 
|| (path.index(access path) == 0) # access to this path 
has file access - true 
end 
end 
if !has file access 
puts "[POLICY] You do not have access to push to #{path}" 
Cs Cie | 
end 
end 
end 


end 


check_directory_perms 
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Most of that should be easy to follow. You get a list of new commits being pushed to your 
server with git rev-list. Then, for each of those, you find which files are modified and make sure 
the user who' s pushing has access to all the paths being modified. One Rubyism that may not be 
clear is path.index(access path) -- 0, which is true if path begins with access path — this ensures that 
access path is not just in one of the allowed paths, but an allowed path begins with each accessed 
path. 

Now your users can' t push any commits with badly formed messages or with modified files outside 


of their designated paths. 


Enforcing Fast-Forward-Only Pushes 


The only thing left is to enforce fast-forward-only pushes. In Git versions 1.6 or newer, you 
can set the receive.denyDeletes and receive.denyNonFastForwards settings. But enforcing this with a hook 
will work in older versions of Git, and you can modify it to do so only for certain users or 


whatever else you come up with later. 





The logic for checking this is to see if any commits are reachable from the older revision 
that aren’ t reachable from the newer one. If there are none, then it was a fast-forward push: 


otherwise, you deny it: 


# enforces fast-forward only pushes 
def check_fast_forward 
missed refs = ‘git rev-list #{$newrev}..#{$oldrev}* 
missed_ref_count = missed_refs.split("\n").size 
if missed_ref_count > 0 
puts "[POLICY] Cannot push a non fast-forward reference" 
exit 1 
end 


end 


check_fast_forward 


Everything is set up. If you run chmod u*x .git/hooks/update, which is the file you into which 
you should have put all this code, and then try to push a non-fast-forwarded reference, you get 


something like this: 


$ git push -f origin master 
Counting objects: 5, done. 
Compressing objects: 100% (3/3), done. 
Writing objects: 100% (3/3), 323 bytes, done. 
Total 3 (delta 1), reused 0 (delta 0) 
Unpacking objects: 100% (3/3), done. 
Enforcing Policies... 
(refs/heads/master) (8338c5) (c5b616) 
[POLICY] Cannot push a non-fast-forward reference 
error: hooks/update exited with error code 1 
error: hook declined to update refs/heads/master 
To git@gitserver:project.git 

! [remote rejected] master -» master (hook declined) 


error: failed to push some refs to 'gitegitserver:project.git' 
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There are a couple of interesting things here. First, you see this where the hook starts running. 


Enforcing Policies... 


(refs/heads/master) (fb8c72) (c56860) 


Notice that you printed that out to stdout at the very beginning of your update script. It' s 
important to note that anything your script prints to stdout will be transferred to the client. 


The next thing you' 11 notice is the error message. 


[POLICY] Cannot push a non fast-forward reference 
error: hooks/update exited with error code 1 


error: hook declined to update refs/heads/master 


The first line was printed out by you, the other two were Git telling you that the update script 


exited non-zero and that is what is declining your push. Lastly, you have this: 


To git@gitserver:project.git 
! [remote rejected] master -» master (hook declined) 


error: failed to push some refs to 'gitegitserver:project.git' 


You’ 11 see a remote rejected message for each reference that your hook declined, and it tells 
you that it was declined specifically because of a hook failure. 
Furthermore, if the ref marker isn’ t there in any of your commits, you’ 11 see the error message 


you’ re printing out for that. 


[POLICY] Your message is not formatted correctly 


Or if someone tries to edit a file they don' t have access to and push a commit containing it, 
they will see something similar. For instance, if a documentation author tries to push a commit 


modifying something in the 1ib directory, they see 


[POLICY] You do not have access to push to lib/test.rb 


That' s all. From now on, as long as that update script is there and executable, your repository 
will never be rewound and will never have a commit message without your pattern in it, and your 


users will be sandboxed. 


7.4.2 Client-Side Hooks 


The downside to this approach is the whining that will inevitably result when your users’ 


commit pushes are rejected. Having their carefully crafted work rejected at the last minute can 
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be extremely frustrating and confusing; and furthermore, they will have to edit their history to 
correct it, which isn' t always for the faint of heart. 

The answer to this dilemma is to provide some client-side hooks that users can use to notify them 
when they' re doing something that the server is likely to reject. That way, they can correct any 
problems before committing and before those issues become more difficult to fix. Because hooks 
aren' t transferred with a clone of a project, you must distribute these scripts some other way 


nd then have your users copy them to their .git/hooks directory and make them executable. You can 


e 


jan 


istribute these hooks within the project or in a separate project, but there is no way to set 
them up automatically. 

To begin, you should check your commit message just before each commit is recorded, so you know 
the server won’ t reject your changes due to badly formatted commit messages. To do this, you can 


add the commit-msg hook. If you have it read the message from the file passed as the first argument 





and compare that to the pattern, you can force Git to abort the commit if there is no match: 


#!/usr/bin/env ruby 
message file = ARGV[0] 


message - File.read(message file) 
$regex = /A[ref: (\d+)\]/ 


if !$regex.match(message) 
puts "[POLICY] Your message is not formatted correctly" 
exit 1 


end 


If that script is in place (in .git/hooks/commit-msg) and executable, and you commit with a message 


that isn' t properly formatted, you see this: 


$ git commit -am 'test' 


[POLICY] Your message is not formatted correctly 


No commit was completed in that instance. However, if your message contains the proper pattern, 


Git allows you to commit: 


$ git commit -am 'test [ref: 132]' 
[master e05c914] test [ref: 132] 


1 files changed, 1 insertions(+), 0 deletions(-) 


Next, you want to make sure you aren’ t modifying files that are outside your ACL scope. If your 
project’ s .git directory contains a copy of the ACL file you used previously, then the following 


pre-commit script will enforce those constraints for you: 


#!/usr/bin/env ruby 
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$user = ENV[ 'USER' | 


# [ insert acl access data method from above ] 


# only allows certain users to modify certain subdirectories in a project 
def check directory perms 


access = get acl access data('.git/acl') 


files modified = ‘git diff-index --cached --name-only HEAD*.split("\n") 
files modified.each do |path| 
next if path.size -- 
has file access - false 
access[S$user].each do [access path| 
if !access path || (path.index(access path) == 0) 
has file access - true 
end 
if !has file access 
puts "[POLICY] You do not have access to push to #{path}" 
exit 1 
end 
end 


end 


check directory perms 


This is roughly the same script as the server-side part, but with two important differences. 
First, the ACL file is in a different place, because this script runs from your working directory, 


not from your Git directory. You have to change the path to the ACL file from this 


access = get acl access data('acl') 


to this: 


access = get acl access data('.git/acl') 


The other important difference is the way you get a listing of the files that have been changed. 
Because the server-side method looks at the log of commits, and, at this point, the commit hasn' t 


been recorded yet, you must get your file listing from the staging area instead. Instead of 


files modified = ‘git log -1 --name-only --pretty-format:'' #{ref}* 


you have to use 


files modified = ‘git diff-index --cached --name-only HEAD* 
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But those are the only two differences — otherwise, the script works the same way. One caveat 
is that it expects you to be running locally as the same user you push as to the remote machine. 
If that is different, you must set the $user variable manually. 

The last thing you have to do is check that you’ re not trying to push non-fast-forwarded 
references, but that is a bit less common. To get a reference that isn' t a fast-forward, you 
either have to rebase past a commit you’ ve already pushed up or try pushing a different local 
branch up to the same remote branch. 

Because the server will tell you that you can' t push a non-fast-forward anyway, and the hook 
prevents forced pushes, the only accidental thing you can try to catch is rebasing commits that 
have already been pushed. 

Here is an example pre-rebase script that checks for that. It gets a list of all the commits 
you’ re about to rewrite and checks whether they exist in any of your remote references. If it 


sees one that is reachable from one of your remote references, it aborts the rebase: 


#!/usr/bin/env ruby 


base branch - ARGV [0] 
if ARGV[1] 

topic branch - ARGV[1] 
else 

topic branch - "HEAD" 


end 


target shas = ‘git rev-list Z(base branch)..Z(topic branch) .split("Nn") 


remote refs = ‘git branch -r^.split("Nn").map ( |r] r.strip } 


target shas.each do |sha| 
remote_refs.each do |remote ref| 
shas pushed = ‘git rev-list ^Z(sha)^e refs/remotes/Z(remote ref)^ 
if shas pushed.split( "Nn" ).include?(sha) 
puts "[POLICY] Commit #{sha} has already been pushed to Z(remote ref)" 
exit 1l 
end 
end 


end 


This script uses a syntax that wasn' t covered in the Revision Selection section of Chapter 6. 


You get a list of commits that have already been pushed up by running this: 


git rev-list “#{sha}“@ refs/remotes/Z(remote ref) 


The SHA*@ syntax resolves to all the parents of that commit. You’ re looking for any commit that 
is reachable from the last commit on the remote and that isn' t reachable from any parent of any 
of the SHAs you' re trying to push up — meaning it' s a fast-forward. 

The main drawback to this approach is that it can be very slow and is often unnecessary — if you 
don’ t try to force the push with -f, the server will warn you and not accept the push. However, 
it' s an interesting exercise and can in theory help you avoid a rebase that you might later have 


to go back and fix. 
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7.5 Summary 


You”ve covered most of the major ways that you can customize your Git client and server to 
best fit your workflow and projects. You” ve learned about all sorts of configuration settings， 
file-based attributes, and event hooks, and you’ ve built an example policy-enforcing server. You 


should now be able to make Git fit nearly any workflow you can dream up. 


180 


第 8 章 


Git 与 其 他 系统 




















世界 不 是 完美 的 。 大 多 数 时候 ， 将 所 有 接触 到 的 项 目 全 部 转向 Git 是 不 可 能 的 。 有 时 我 们 不 得 不 为 某 个 项 
使 用 其 他 的 版 本 控制 系统 (VCS, Version Control System ) ， 其 中 比较 常见 的 是 Subversion 。 你 将 在 本 
章 的 第 一 部 分 学 习 使 用 git svn , Git 为 Subversion 附带 的 双向 桥接 工具 。 

或 许 现在 你 已 经 在 考虑 将 先前 的 项 目 转向 Git 。 本 章 的 第 二 部 分 将 介绍 如 何 将 项 目 迁 移 到 Git: 先 介绍 从 
Subversion 的 迁移 ， 然 后 是 Perforce， 最 后 介绍 如 何 使 用 自 定义 的 脚本 进行 非 标准 的 导入 。 



























































































































































































































































8.1 Git 与 Subversion 










































































当前 ， 大 多 数 开发 中 的 开源 项 目 以 及 大 量 的 商业 项 目 都 使 用 Subversion 来 管理 源码 。 作 为 最 流行 的 开源 版 
本 控制 系统 ，Subversion 已 经 存在 了 接近 十 年 的 时 间 。 它 在 许多 方面 与 CVS 十 分 类 似 ， 后 者 是 前 者 出 现 之 前 
代码 控制 世界 的 霸主 。 
Git 最 为 重要 的 特性 之 一 是 名 为 git sva 的 Subversion 双向 桥接 工具 。 该 工具 把 Git 变 成 了 Subversion 
服务 的 客户 端 ， 从 而 让 你 在 本 地 享受 到 Git 所 有 的 功能 ， 而 后 直接 向 Subversion 服务 器 推送 内 容 ， 仿 佛 在 
本 地 使 用 了 Subversion 客户 端 。 也 就 是 说 ， 在 其 他 人 忍受 古董 的 同时 ， 你 可 以 在 本 地 享受 分 文 合 并 ， 使 暂 存 
区 域 ， 衍 合 以 及 单项 挑 拣 等 等 。 这 是 个 让 Git 偷偷 潜入 合作 开发 环境 的 好 东西 ， 在 帮助 你 的 开发 同伴 们 提高 
效率 的 同时 ， 它 还 能 帮 你 劝说 团队 让 整个 项 目 框架 转向 对 Git 的 支持 。 这 个 Subversion 之 桥 是 通 向 分 布 式 
版 本 控制 系统 (DVCS，Distributed VCS ) 世界 的 神奇 隧道 。 







































































































































































































































































































































































































































































8.1.1 git svn 














Git 中 所 有 Subversion 桥接 命令 的 基础 是 sit svn 。 所 有 的 命令 都 从 它 开始 。 相 关 的 命令 数目 不 少 ， 你 将 
通过 几 个 简单 的 工作 流程 了 解 到 其 中 常见 的 一 些 。 
值得 警戒 的 是 ， 在 使 用 eit sva 的 时 候 ， 你 实际 是 在 与 Subversion RA, Git 比 它 要 高 级 复杂 的 多 。 尽 管 
可 以 在 本 地 随意 的 进行 分 文 和 合并 ， 最 好 还 是 通过 衍 合 保持 线性 的 提交 历史 ， 尽 量 避 免 类 似 与 远程 Git 仓库 
动态 交互 这 样 的 操作 。 

避免 修改 历史 再 重新 推送 的 做 法 ， 也 不 要 同时 推送 到 并 行 的 Git 仓库 来 试图 与 其 他 Git 用 户 合 作 。Suber- 
sion 只 能 保存 单一 的 线性 提交 历史 ， 一 不 小 心 束 会 被 搞 糊涂 。 合 作 团队 中 同时 有 人 用 SVN 和 Git, 一 定 要 确 
保 所 有 人 都 使 用 SVN 服务 来 协作 一 一 这 会 让 生活 轻松 很 多 。 
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8.1.2 初始 设 定 
























































为 了 展示 功能 ， 先 要 一 个 具有 写 权 限 的 SVN 人 仓库。 如果 想 尝试 这 个 范例 ， 你 必须 复制 一 份 其 中 的 测试 仓 
库 。 比 较 简 单 的 做 法 是 使 用 一 个 名 为 svnsyne 的 工具 。 较 新 的 Subversion 版 本 中 都 带 有 该 工具 ， 它 将 数据 编 
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其 他 系统 

















码 为 用 于 网 络 传输 的 格式 。 























REBAR, j 











$ mkdir /tmp/test-svn 


$ svnadmin create /tmp/test-svn 





然后 ， 人 允许 所 有 











脚本 : 























在 本 地 新 建 一 个 Subversion 仓库 : 

















户 修 改 revprop 简单 的 做 法 是 添加 





$ cat /tmp/test-svn/hooks/pre-revprop-change 


#!/bin/sh 


exit 0; 


$ chmod +x /tmp/test-svn/hooks/pre-revprop-change 





现在 可 以 调用 



































svnsync init 加 目标 仓库 ， 再 加 源 仓库 的 格式 引 
































个 总 是 


JUN AE 


以 0 作为 返 


Scott Chacon Pro Git 

















g 
— 
































yas! 


把 该 项 




















$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/ 


zx. 


这 将 建立 





进行 同步 所 需 的 忆 











"uni 
A 


p 




















$ svnsync sync file:///tmp/test-svn 


Committed rev 


ision 1. 


Copied properties for revision 1. 


Committed rev 


ision 2. 


Copied properties for revision 2. 


Committed rev 


别 看 这 个 





ision 3. 




















操作 只 花 掉 几 分 














， 要 是 你 想 把 源 仓库 复制 到 另 一 个 远程 仓库 ， 而 不 是 本 地 仓库 





























一 个 小 时 ， 
































尽管 项 RAT 














Fà 








里 ， 然 后 周而复始 一 一 惊人 的 


8.1.3 入 门 





始 ， 它 会 把 整个 Subversion 仓库 导入 到 一 个 本 地 的 Git 仓库 中 。 提 醒 























氏 效 ， 但 是 我 们 别 无 选择 。 





生 。 可 以 通过 运行 以 下 命令 来 元 隆 代码 : 




















同步 到 本 地 了 : 


直 的 pre-revprop-change 























那 将 花 掉 接 近 














到 100 次 的 提交 。 Subversion 每 次 只 复制 











WEH, F 























有 了 可 以 写 入 的 Subversion CENA, DW AAR PARIS 




















Subversion 仓库 ， 所 以 应 该 把 下 面 的 file:///tmp/test-svn 换 

















$ git svn clone file:///tmp/test-svn -T trunk -b branches -t tags 


作 流 程 了 。 我 们 从 eit svn clone 命令 





















































成 你 所 用 








的 Su 


Initialized empty Git repository in /Users/schacon/projects/testsvnsync/svn/.git/ 

rl = b4e387bc68740b5af56c2a5faf4003ae42bd135c (trunk) 
A m4/acx pthread.m4 
A m4/stl hash.m4 
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它 推送 到 另 一 个 仓库 


























下 ， 这 里 导入 的 是 








个 货真价实 的 














bversion 仓库 的 URL: 


Scott Chacon Pro Git 


8.1% Git 5 Subversion 


r75 = d1957f3b307922124eec6314e15bcda59e3d9610 (trunk) 
Found possible branch point: file:///tmp/test-svn/trunk => \ 
file:///tmp/test-svn /branches/my-calc-branch, 75 


Found branch parent: (my-calc-branch) dl 
Following parent with do switch 


Successfully followed parent 


957£3b307922124eec6314e15bcda59e3d9610 


r76 = 8624824eccObadd73f40ea2f01fce51894189b01 (my-calc-branch) 


Checked out HEAD: 


file:///tmp/test-svn/branches/my-calc-branch r76 

















这 相当 于 针对 所 提供 的 URL 运行 了 两 条 命令 




















— git svn init 加 上 gitsvn fetch ° 可 能 会 花 上 一 段 时 间 ie 我 






















































































至 数 天 。 


-T trunk -b branches -t tags 告诉 Git 该 Subversion 仓库 遵循 了 基本 的 分 支 和 标签 命名 JEM o 如 你 的 主 


们 所 用 的 测试 项 目 仅 仅 包 含 75 次 提交 并 且 它 的 代码 量 不 算 大 ， 所 以 只 有 几 分 钟 而 已 。 不 过 ，Git 仍然 需要 提 
取 每 一 个 版 本 ， 每 次 一 个 ， 再 逐个 提交 。 对 于 一 个 包含 成 百 上 千 次 提交 的 项 目 ， 花 掉 的 时 间 则 可 能 是 儿 小 时 其 
































































































































干 (译注 ，trunk， 相 当 于 非 分 布 式 版 本 控制 里 的 master 分 支 ， 代 表 开 发 的 主线 ) ， 分 支 或 者 标签 以 不 同 的 方式 



























































命名 ， 则 应 做 出 相应 改变 。 由 于 该 济 
Standard layout 的 首 字母 ) ， 也 就 
































$ git svn clone file:///tmp/test-svn -s 




















则 的 第 见 性 ， 可 以 使 用 -s 来 代替 整 条 命令 ， 它 意味 着 标准 布局 (s 是 
是 前 面 选项 的 内 容 。 下 面 的 命令 有 相同 的 效果 ; 



















































































现在 ， 你 有 了 一 个 有 效 的 Git 仓库 ， 包 含 着 导入 的 分 文 和 标签 : 























e 


git branch -a 

master 
my-calc-branch 
tags/2.0.2 
tags/release-2.0.1 
tags/release-2.0.2 
tags/release-2.0.2rcl 


trunk 













































































值得 注意 的 是 ， 该 工具 分 配 命名 空间 时 和 远程 引用 的 方式 不 尽 相同 。 克 隆 普 通 的 Git 仓库 时 ， 可 以 以 

























































































origin/[branch] 的 形式 获取 远程 服务 器 上 所 有 可 用 的 分 支 一 一 分 配 到 远程 服务 的 名 称 下 。 然 而 git svn 假定 不 
存在 多 个 远程 服务 器 ， 所 以 把 所 有 指向 远程 服务 的 引用 不 加 区 分 的 保存 下 来 。 可 以 用 Git 探测 命令 show-ref 

































































来 查看 所 有 引用 的 全 名 。 




















$ git show-ref 

1cbd49044d9982f386d87f88fcelc24ad7c0f0471 
aeelecc26318164f355a883f5d99cf f0c852d3c4 
03d09b0e2aad427e34a6d50ff147128e76c0e0f5 
50d02cc0adc9da4319eeba0900430ba219b9c376 
4caaa711a50c77879a9158b90380060f672'745cb 
1c4cb508144c513ff1214c3488abe66dcb92916f 
1cbd49044d9982f386d87f88fcelc24ad7c0f0471 






























































refs/heads/master 
refs/remotes/my-calc-branch 
refs/remotes/tags/2.0.2 
refs/remotes/tags/release-2.0.1 
refs/remotes/tags/release-2.0.2 
refs/remotes/tags/release-2.0.2rcl 


refs/remotes/trunk 
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$8 





而 普通 





X Git 5 











其 他 系统 





的 Git PEMA MRA 








$ git show-ref 

83e38c7a0af325a9722f2fdc56b10188806d83al 
3e15e38c198baac84223acf c6224bb8b99f 12281 
0a30dd3b0c795b80212ae723640d4e5d48cabdff 
25812380387fdd55f916652be4881c6f11600d6f 


































































































IHR 


refs/heads/master 
refs/remotes/gitserver/master 
refs/remotes/origin/master 


refs/remotes/origin/testing 
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这 里 有 两 个 远程 服务 器 : 一 个 名 为 gitserver , 具有 一 个 master 分 支 ; 另 一 个 叫 origin， 具有 master 和 
testing 个 分 支 e 

注意 本 例 中 通过 sit svn 导入 的 远程 引用 ， (Subversion 的 ) 标 签 是 当 作 远 程 分 支 添 加 的 ， 而 不 是 真正 的 
Git 标签 。 导 入 的 Subversion 仓库 仿佛 是 有 一 个 带 有 不 同 分 支 的 tags 远程 服务 器 
8.1.4 提交 到 Subversion 

有 了 可 以 开展 工作 的 (本地) 仓库 以 后 ， 你 可 以 开始 对 该 项 目 做 出 贡献 并 向 上 游 仓 库 提 交 内 容 了 ，Git 这 
时 相当 于 一 个 SVN 客户 端 。 假 如 编辑 了 一 个 文件 并 进行 提交 ， 那 么 这 次 提交 仅 存 在 于 本 地 的 Git 而 非 
Subversion 服务 器 上 


$ git commit -am 'Adding git-svn instructions to the README 
[master 97031e5] Adding git-svn instructions to the README 


1 files changed, 


ETR, 





1 insertions(+), 





可 以 将 作出 的 修改 推 





送 到 





1 deletions(-) 











上 游 。 值 得 注 

















在 离线 状态 下 

















是 git svn dcommit: 


$ git svn 


dcommi t 


Committing to file:///tmp/test-svn/trunk ... 


M 
Commi tted 
M 


README. txt 
r79 
README. txt 


r79 = 938b1a547c2cc92033b74d32030e86468294a5c8 (trunk) 


No changes between current HEAD and refs/remotes/trunk 


Resetting to the latest refs/remotes/trunk 


所 








有 在 原 Subversion #4 
将 被 重 写 ， 加 入 








同时 使 用 











git log 





尔 会 找到 

































































Git 和 Subversion 
新 添加 以 git-svn-id (译注 : 
EI 


EAE, Subversion 的 使 用 
进行 多 次 提交 然后 一 次 性 的 推送 到 Subversion 的 服务 器 上 。 向 Subversion 服务 器 推 























据 基础 上 提交 的 commit 会 一 一 提交 到 Subversion, 
个 特别 标识 。 这 一 步 很 重要 ， 因 为 它 意味 着 所 有 commit 的 SHA-1 指 都 会 发 生变 化 。 









































即 本 段 开头 所 说 的 特别 标识 ) 


commit 938b1a547c2cc92033b74d32030e86468294a5c8 


Author: 
Date: 
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schacon «schacona4c93b258-373f-11de-be05-5f7a86268029- 
Sat May 2 22:06:44 2009 +0000 


种 服务 作为 远程 服务 不 是 个 好 主意 的 原因 之 一 。 检 视 以 下 最 后 一 





流程 也 因此 改变 了 一 一 你 可 以 














送 的 命令 


然后 你 本 地 Git 的 commit 
这 也 是 


个 commit, 























Scott Chacon Pro Git 


Adding git-svn instructions to the README 


git-svn-id: file:///tmp/test-svn/trunk@79 4c93b258-373f-11de-be05-5f7a86268029 














成 以 后 























头 的 SHA-1 校 验 值 在 提交 完 


bversion 远程 


注意 看 ， 原 本 以 9703165 
器 推送 内 容 ， 又 要 推送 到 Su 
改变 所 提交 的 数据 内 容 。 









































8.1.5 拉 取 最 新 进展 















































服务 器 ， 则 必须 先 向 Subversion 



























































8.1 节 Git 




















"5g | 938b1a5 。 如 果 既 要 癌 











推送 (dcommit) 













































































如 果 要 与 其 他 开发 者 协作 ， 总 有 那么 一 天 你 推送 完毕 之 后 ， 其 他 人 发 现 他 们 推送 
的 内 容 ) 产生 冲突 。 这 些 修改 在 你 合并 之 前 将 一 直 被 拒绝 。 在 git svn 里 这 种 情况 形似 : 
$ git svn dcommit 
Committing to file:///tmp/test-svn/trunk ... 
Merge conflict during commit: Your file or directory 'README.txt' is probably \ 
out-of-date: resource out of date; try updating at /Users/schacon/libexec/git-\ 
core/git-svn line 482 
为 了 解决 该 问题 ， 可 以 运行 git svn rebase ， 它 会 拉 取 服务 器 上 所 有 最 新 的 改变 ， 再 次 基础 





改 : 


$ git svn rebase 

M README. txt 
r80 = ff829ab914e8775c7c025d741beb3d523ee30bc4 (trunk) 
First, rewinding head to replay your work on top of it... 


Applying: first user change 











Tr 























现在 ， 你 做 出 的 修改 都 发 生 在 服 


$ git svn dcommit 


Committing to file:///tmp/test-svn/trunk ... 


M README. txt 
Committed r81 
M README. txt 


r81 = 456cbe6337abe49154db70106d1836bc1332deed (trunk) 
No changes between current HEAD and refs/remotes/trunk 


Resetting to the latest refs/remotes/trunk 






























































需要 牢记 的 一 点 是 ，Git 要 求 我 们 在 推送 之 前 先 合 
时 候 才 这 样 做 。 假 如 有 人 向 一 个 文件 推送 了 一 些 修 改 ， 这 时 
下 党 作 : 
































上 游 仓 库 中 最 新 的 内 容 ， 而 sit svn 





尔 要 向 男 一 个 文 作 
































之 后 ， 所 以 可 以 顺利 的 运行 dcommit : 





只 要 求 存在 7 


与 Subversion 





Git 远程 服务 
丸 为 该 操作 会 




















,修改 的 时 候 (与 你 推送 


上 衍 合 你 的 修 








! 突 的 























推送 一 些 修 改 ， 导 





BA dcommit 将 
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$ git svn dcommit 


其 他 系统 


Committing to file:///tmp/test-svn/trunk ... 


M 
Committed r84 
M 
r83 = 
M 
r84 = 


configure.ac 


autogen.sh 


configure.ac 


8aa54a74d452f82eee10076ab2584c1lfc424853b (trunk) 


cdbac939211ccb18aa744e581e46563af5d962d0 (trunk) 


W: d2f23b80f67aaaalf6f5aaef48fce3263ac71a92 and refs/remotes/trunk differ, 


using rebase: 


:100755 100755 efaba59965fbbb5b2b0a12890flb351bb5493c18 \ 
015e4c98c482f0fa71e4d5434338014530b37fa6 M 


First, 
Nothing to do. 











autogen.sh 


rewinding head to replay your work on top of it... 
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这 一 点 需要 牢记 ， 因 为 它 的 结果 是 推送 之 后 项 目 处 于 一 个 不 完整 存在 与 任何 主机 上 的 状态 。 如 果 做 出 的 修改 
无 法 兼容 但 没有 产生 冲突 ， 则 可 能 造成 一 些 很 难 确诊 的 难题 。 这 和 使 用 Git 服务 器 是 不 同 的 一 一 在 Git 世界 
里 ， 发 布 之 前 ， 你 可 以 在 客户 端 系统 里 完整 的 测试 项 目的 状态 ， 而 在 SVN 永远 都 没 法 确保 提交 前 后 项 目的 状 
态 完全 一 样 。 

及 时 还 没 打算 进行 提交 ， 你 也 应 该 用 这 个 命令 从 Subversion 服务 器 拉 取 最 新 修改 。sit svn fetch 能 获取 最 
新 的 数据 ， 不 过 git svn rebase 才 会 在 获取 之 后 在 本 地 进行 更 新 。 
$ git svn rebase 

M generate descriptor proto.sh 
r82 = bdl6df9173e424c6f52c337ab6efa7f7643282f1 (trunk) 
First, rewinding head to replay your work on top of it... 
Fast-forwarded master to refs/remotes/trunk. 

不 时 地 运行 一 下 git svn rebase 可 以 确保 你 的 代码 没有 过 时 。 不 过 ， 运 行 该 命令 时 需要 确保 工作 目录 的 整 
洁 。 如 果 在 本 地 做 了 修改 ， 则 必须 在 运行 git svn rebase 之 前 或 暂 存 工作 ， 或 暂时 提交 内 容 一 一 否则 ， 该 命令 
会 发 现 衍 合 的 结果 包含 着 冲突 因而 终止 。 

8.1.6 Git 分 支 问题 

习惯 了 cit 的 工作 流程 以 后 ， 你 可 能 会 创建 一 些 特性 分 支 ， 完 成 相关 的 开发 工作 ， 然 后 合并 他 们 。 如 果 要 

git svn 向 Subversion 推送 内 容 ， 那 么 最 好 是 每 次 用 衍 合 来 并 入 一 个 单一 分 支 ， 而 不 是 直接 合并 。 使 用 
衍 合 的 原因 是 Subversion 只 有 一 个 线性 的 历史 而 不 像 Git 那样 处 理 合并 ， 所 以 Git svn 在 把 快照 转换 为 
Subversion 的 commit 时 只 能 包含 第 一 个 祖先 。 

假设 分 支 历史 如 下 : 创建 一 个 experiment 分 文 ， 进 行 两 次 提交 ， 然 后 合并 到 master ° E dcommit 的 时 候 会 得 





到 如 下 输出 


Ly: 


$ git svn dcommit 


Committing to file:///tmp/test-svn/trunk ... 


M 
Committed r85 
M 
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CHANGES . txt 


CHANGES . tx t 
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r85 = Abfebeec434d156c36f2bcd18f4e3d97dc3269a2 (trunk) 
No changes between current HEAD and refs/remotes/trunk 
Resetting to the latest refs/remotes/trunk 
COPYING.txt: locally modified 

INSTALL.txt: locally modified 


M COPYING. txt 

M INSTALL.txt 
Committed r86 

M INSTALL.txt 

M COPYING. txt 


r86 = 2647f6b86ccfcaad4ec58c520e369ec81f7c283c (trunk) 
No changes between current HEAD and refs/remotes/trunk 


Resetting to the latest refs/remotes/trunk 























mil 


在 一 个 包含 了 合并 历史 的 分 支 上 使 用 dcommit 可 以 成 功 运行 ， 不 过 在 Git 项 目的 历史 中 ， 它 没有 重 写 你 在 
experiment 分 支 : 的 j^^ commit 一 一 另 一 方面 ， 这 些 改变 却 出 现在 了 SVN 版 本 中 同一 个 合 commi t 中 o 

在 别人 克隆 该 项 目的 时 候 ， 只 能 看 到 这 个 合并 comit 包含 了 所 有 发 生 过 的 修改 ;他 们 无 法 获知 修改 的 作者 
和 时 间 等 提交 信息 。 




















































































































































































































8.1.7 Subversion 分 支 






























































Subversion 的 分 支 和 Git 中 的 不 尽 相 同 ， 避 免 过 多 的 使 用 可 能 是 最 好 方案 。 不 过 , 用 git svn 创建 和 提 
交 不 同 的 Subversion 分 支 仍 是 可 行 的 。 


Fd 














创建 新 的 SVN 分 支 








要 在 Subversion 中 建立 一 个 新 分 支 ， 需要 运行 git svn branch [分 支 名 ] To create a new branch in 








Subversion, you run git svn branch [branchname] : 


$ git svn branch opera 

Copying file:///tmp/test-svn/trunk at r87 to file:///tmp/test-svn/branches/opera... 

Found possible branch point: file:///tmp/test-svn/trunk => \ 
file:///tmp/test-svn/branches/opera, 87 

Found branch parent: (opera) lf6bfe471083cbca06ac8d4176f7ad4de0d62e5f 

Following parent with do switch 

Successfully followed parent 

r89 = 9b6fe0b90c5c9adf9165f700897518dbc54a7cbf (opera) 











相当 于 在 Subversion 中 的 svn copy trunk branches/opera 命令 H 对 Subversion 服务 器 进行 了 相关 操作 o 
值得 提醒 的 是 它 没有 检 出 和 转换 到 那个 分 支 ， 如 果 现 在 进行 提交 ， 将 提交 到 服务 器 上 的 trunk, 而 非 opera? 














































































































8.1.8 切换 当前 分 支 












































Git 通过 搜寻 提交 历史 中 Subversion 分 支 的 头 部 来 决定 dcommit 的 目的 地 一 一 而 它 应 该 只 有 一 个 ， 那 就 
是 当前 分 支 历史 中 最 近 一 次 包含 git-svn-id 的 提交 ° 
如 果 需 要 同时 在 多 个 分 支 上 提交 ， 可 以 通过 导入 Subversion 上 某 个 其 他 分 支 的 commit 来 建立 以 该 分 支 为 
dcommit 目的 地 的 本 地 分 支 。 比 如 你 想 拥 有 一 个 并 行 维护 的 opera 分 支 ， 可 以 运行 
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$ git branch opera remotes/opera 










































































































































































































































































然后 ， 如 果 要 把 opera 分 支 并 入 trunk (本 地 的 master 分 支 ) ， 可 以 使 用 普通 的 git merge。 不 过 最 好 提供 

条 描述 提交 的 信息 (通过 -m) ， 否 则 这 次 合并 的 记录 是 Merge branch opera ， 而 不 是 任何 有 用 的 东西 。 

记 住 ， 虽 然 使 用 了 git merge 来 进行 这 次 操作 ， 合并 过 程 可 能 比 使 用 Subversion 简单 一 些 (因为 Git 
会 自动 找到 适合 的 合并 基础 ) ， 这 并 不 是 一 次 普通 的 Git 合并 提交 。 最 终 它 将 被 推送 回 commit 无 法 包含 多 























































































































个 祖先 的 Subversion 服务 器 上 ， 因 而 在 推送 之 后 ， 它 将 变 成 一 个 包含 了 所 有 在 其 他 分 支 上 做 出 的 改变 的 音 
一 commit。 把 一 个 分 支 合 并 到 另 一 个 分 文 以 后 ， 你 没 法 像 在 Git 中 那样 轻易 的 回 到 那个 分 文 上 继续 工作 。 提 
区 时 运行 的 dcommit 命令 擦 除了 全 部 有 关 哪 个 分 支 被 并 入 的 信息 ， 因 而 以 后 的 合并 基础 计算 将 是 不 正确 的 一 一 
dcommit 让 git merge 的 结果 变 得 类 似 于 git merge --squash。 不 笠 的 是 ， 我 们 没有 什么 好 办 法 来 避免 该 情况 
Subversion 无 法 储存 这 个 信息 ， 所 以 在 使 用 它 作为 服务 器 的 时 候 你 将 永远 为 这 个 缺陷 所 困 。 为 了 不 出 现 这 种 
问题 ， 在 把 本 地 分 支 (本 例 中 的 opera) 并 入 trunk 以 后 应 该 立即 将 其 删除 。 







































































































































































































































































































































































8.1.9 对 应 Subversion 的 命令 


git svn 工具 集合 了 若干 个 与 Subversion 类 似 的 功能 ， 对 应 的 命令 可 以 简化 向 Git 的 转化 过 程 。 下 1 
命令 能 实现 Subversion 的 这 些 功能 














I 











z 

















SVN 风格 的 历史 


























习惯 了 Subversion 的 人 可 能 想 以 SVN 的 风格 显示 历史 ， 运 行 git svn log 可 以 让 提交 历史 显示 为 SVN 格 
kw 


$ git svn log 


r87 | schacon | 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009) | 2 lines 


autogen change 


r86 | schacon | 2009-05-02 16:00:21 -0700 (Sat, 02 May 2009) | 2 lines 


Merge branch 'experiment' 


r85 | schacon | 2009-05-02 16:00:09 -0700 (Sat, 02 May 2009) | 2 lines 


updated the changelog 














关于 git svn log , 有 两 点 需要 注意 ° HJC, 它 可 以 离线 工作 ， 不 像 svn log MS, 需要 向 Subversion 服 
务 器 索取 数据 。 其 次 ， 它 仅仅 显示 已 经 提交 到 Subversion 服务 器 上 的 commit。 在 本 地 尚未 dcommit AY Git 
数据 不 会 出 现在 这 里 ;其 他 人 向 Subversion 服务 器 新 提交 的 数据 也 不 会 显示 。 等 于 说 是 显示 了 最 近 已 知 
Subversion 服务 器 上 的 状态 。 




















































































































SVN 日 志 








类 似 git svn log 对 git log 的 模拟 ， svn annotate 的 等 效 命 令 = 是 git svn blame [文件 名 ]。 其 输出 如 下 : 
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$ git svn blame README. txt 
temporal Protocol Buffers - Google's data interchange format 
temporal Copyright 2008 Google Inc. 
temporal http://code.google.com/apis/protocolbuffers/ 
temporal 

22 temporal C** Installation - Unix 

22 temporal ======================= 

2 temporal 
79 schacon Committing in git-svn. 
78 schacon 

2 temporal To build and install the C++ Protocol Buffer runtime and the Protocol 

temporal Buffer compiler (protoc) execute the following: 


temporal 




















同样 ， 它 不 显示 本 地 的 Git 提交 以 及 Subversion 上 后 来 更 新 的 内 容 。 























SVN 服务 器 信息 























还 可 以 使 用 sit svn info 来 获取 与 运行 svn into 类 似 的 信息 : 








$ git svn info 

Path: . 

URL: https://schacon-test.googlecode.com/svn/trunk 
Repository Root: https://schacon-test.googlecode.com/svn 
Repository UUID: 4c93b258-373f-11de-be05-5f7a86268029 
Revision: 87 
Node Kind: directory 

Schedule: normal 

Last Changed Author: schacon 

Last Changed Rev: 87 

Last Changed Date: 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009) 









































ESj blame 和 toe 的 相同 点 在 于 离线 运行 以 及 只 更 新 到 最 后 一 次 与 Subversion 服务 器 通信 的 状态 。 





























略 Subversion 之 所 略 














假如 克隆 了 一 个 包含 了 svn:ignore 属性 的 Subversion 仓库 ， 就 有 必要 建立 对 应 的 .gitignore 文件 来 防止 意 
外 提交 一 些 不 应 该 提交 的 文件 。git svn 有 两 个 有 益 于 改善 该 问题 的 命令 。 第 一 个 是 git svn create-ignore, EA 
动 建立 对 应 的 .gitignore 文件 ， 以 便 下 次 提交 的 时 候 可 以 包含 它 。 

第 二 个 命令 是 git svn show-ignore， 它 把 需要 放 进 .gitignore WH 


GE ELT EKRAR: 
























































23 



































T 





IAN ASST DEI ese HD, AEREA H 








LL 


























(ml 

















$ git svn show-ignore > .git/info/exclude 






























































Id 
I 














这 样 一 来 ， 避 免 了 .gitignore 对 项 目的 干扰 。 如 果 你 是 一 个 Subversion 团队 里 
队友 不 喜欢 项 目 包含 .gitignore， 该 方法 是 你 的 不 二 之 选 。 











E—RJ Git 用 户 ， 而 其 他 
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8.1.10 Git-Svn 总 结 

git svn 工具 集 在 当前 不 得 不 使 用 Subversion 服务 器 或 者 开发 环境 要 求 使 用 Subversion 服务 器 的 时 候 格外 
有 用 “。 不 妨 把 它 看 成 一 个 跋 脚 的 Git， 然 而 ， 你 还 是 有 可 能 在 转换 过 程 中 碰 到 一 些 困惑 你 和 合作 者 们 的 迷 题 。 
为 了 避免 麻烦 ， 试 着 遵守 如 下 守则 ; 





































































































































































































” 保持 一 个 不 包含 由 git merge 生成 的 commit 的 线性 提交 历史 。 将 在 主线 分 支 外 进行 的 开发 通通 衍 合 回 主 
线 ， 避 免 直 接合 并 。 

不 要 单独 建立 和 使 用 一 个 Git 服务 来 搞 合作 。 可 以 为 了 加 速 新 开发 者 的 克隆 进程 建立 一 个 ， 但 是 不 要 癌 
它 提供 任何 不 包含 git-svn-id 条 目的 内 容 。 甚 至 可 以 添加 一 个 pre-receive 挂 钧 来 在 每 一 个 提交 信息 中 查 
FÈ git-svn-id 绝 提 交 那 些 不 包含 它 的 commit o 


























































































































































































































ni nb» ya 

































































如 果 遵 循 这 些 守 则 ， 在 Subversion 上 工作 还 可 以 接受 。 然 而 ， 如 果 能 迁徙 到 真正 的 Git 服务 器 ， 则 能 为 团 
队 带 来 更 多 好 处 。 






































8.2 迁移 到 Git 












































如 果 在 其 他 版 本 控制 系统 中 保存 了 某 项 目的 代码 而 后 决定 转 而 使 用 Git， 那 么 该 项 目 必须 经 历 某 种 形式 的 迁 
移 。 本 市 将 介绍 Git 中 包含 的 一 些 针对 常见 系统 的 导入 脚本 ， 并 将 展示 编写 自 定义 的 导入 脚本 的 方法 。 





























































































































8.2.1 导入 


你 将 学 习 到 如 何 从 专业 重量 级 的 版 本 控制 系统 中 导入 数据 一 一 Subversion 和 Perforce 一 一 因为 据 我 所 
知 这 二 者 的 用 户 是 (向 Git) 转换 的 主要 群体 ， 而 且 Git 为 此 二 者 附带 了 高 质量 的 转换 工具 。 




























































































8.2.2 Subversion 


读 过 前 一 节 有 关 sit sv 的 内 容 以 后 ， 你 应 该 能 轻而易举 的 根据 其 中 的 指导 来 sit svn clone 一 个 仓库 了 ; 然 
LH. BE Subversion 的 使 用 ， 向 一 个 新 Git server 推送 ， 并 开始 使 用 它 。 想 保留 历史 记录 ， 所 画 的 时 间 应 
该 不 过 就 是 从 Subversion 服务 器 拉 取 数据 的 时 间 (可 能 要 等 上 好 一 会 就 是 

然而 ， 这 样 的 导入 并 不 完美 ;而 且 还 要 花 那 么 多 时 间 ， 不 如 干脆 一 次 把 它 做 对 ! 首当其冲 的 任务 是 作者 信 
个 提交 者 在 都 在 主机 上 有 一 个 用 户 名 ， 记 录 在 提交 信息 中 。 上 和 节 例子 中 多 处 显示 了 
schacon ， 比 如 blame 的 输出 以 及 git svn log。 如 果 想 让 这 条 信息 更 好 的 映射 到 Git 作者 数据 里 ， 则 需要 从 
Subversion 用 户 名 到 Git 作者 的 一 个 映射 关系 。 建 立 一 个 叫做 user.txt 的 文件 ， 用 如 下 格式 表示 映射 关系 : 











































































































































































































































































































» 
Aft Subversion, 8 





















































































































































schacon = Scott Chacon «schaconageemail.com- 


selse = Someo Nelse <selse@geemail .com> 





通过 该 命令 可 以 获得 SVN 作者 的 列 对 


iun 








$ svn log --xml | grep author | sort -u | perl -pe 's/.>(.?)<./$1 = /' 


























然后 从 XML ! 取出 需要 的 信息 。 
定向 到 user.txt 文件 ， 然 后 就 可 








它 将 输出 XML 格式 的 日 志 一 一 你 可 以 找到 作者 ， 建 立 一 个 单独 的 列 
(显而易见 ， 本 方法 要 求 主机 上 安装 了 grep，sort 和 perl.) 然后 把 输 
以 在 每 一 项 的 后 面 添加 相应 的 Git 用 户 数据 。 








x 


EF. 
co ¢ 
imli 











= 
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N 











git svn 提供 ZA 














该 文件 可 以 然 它 更 精确 的 映射 作者 数据 。 你 还 可 以 在 clone 或 者 init 后 面 添加 --no-metadata 









































IH ZZ 





ES 





IE git svn BS 


B#E Subversion 的 附加 信息 。 这 样 import 命令 就 变 成 了 : 





$ git-svn clone http://my-project.googlecode.com/svn/ \ 
--authors-file-users.txt --no-metadata -s my project 





DR 








DH 
am 
BE 





WES T ° 原来 的 commit 看 上 


























现在 my project 





录 下 导入 的 Subversion 应 该 比 原来 整洁 








commit 37efa680e8473b615de980fa935944215428a35a 


Author: 


schacon <schacon@4c93b258-373f-11de-be05-5£7a86268029> 


Date: Sun May 3 00:12:22 2009 +0000 


fixed install - go to trunk 


git-svn-id: https://my-project.googlecode.com/svn/trunke94 4c93b258-373f-llde- 


be05-5f7a86268029 


DR 





现在 是 这 村 


commit 03a8785f44c8ea5cdb0e8834b7c8e6c469be2ff2 


Author: Scott Chacon <schacon@geemail.com> 
Date: Sun May 3 00:12:22 2009 +0000 


fixed install - 


go to trunk 





























不 仅 作者 一 项 














你 还 ` 需 要 一 A post-import (导入 后 


) 
构 。 首 先 要 移动 标签 ， 把 它们 从 奇怪 的 远程 




















要 把 标签 变 成 合适 的 Git ME, IBA 


净 了 不 少 ，git-svn-id 也 就 此 消失 了 。 
清理 工作 。 最 起 码 的 ， 应 该 清理 下 git svn 创建 的 那些 怪异 的 索引 结 


分 文 变 成 实际 的 标签 ， 然 后 把 剩 下 的 分 文 移动 到 本 地 。 























































































































T 











yet 





$ cp -Rf .git/refs/remotes/tags/* .git/refs/tags/ 


$ rm -Rf .git/refs/remotes/tags 


该 命 





令 
来 


BEP 














IE 



































将 原本 以 tag/ 开头 的 远程 分 支 的 索引 变 成 真正 的 (轻巧 的 ) 标签 。 
， 把 refs/remotes 下 面 剩 下 的 索引 变 成 本 地 分 文 : 
































$ cp -Rf .git/refs/remotes/* .git/refs/heads/ 
$ rm -Rf .git/refs/remotes 

































































现在 所 有 的 | 

















新 建 的 Git 服务 器 添加 为 远程 服务 器 并 且 向 它 # 














分 支 都 变 成 真正 的 Git 分 支 ， 所 有 的 旧 标 签 也 变 成 真正 的 Git 标签 。 最 后 一 项 工作 就 是 把 
华 送 。 为 了 让 所 有 的 分 文 和 标签 都 得 到 上 传 ， 我 们 使 用 这 条 命 
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$ git push origin --all 














所 有 的 分 文 和 标签 现在 都 应 该 整齐 


8.2.3 Perforce 








ap oz 


不 过 它 是 














含 在 源码 的 con 
以 在 git.kernel.org PRX: 
































你 将 了 解 到 的 下 一 个 被 导入 的 系统 是 Perforce. Git 发 行 的 时 候 
trib 部 分 一 一 而 不 像 git swm 那样 默认 可 用 。 运 行 它 之 前 必须 获取 Git 的 源码 ， 可 


$ git clone git://git.kernel.org/pub/scm/git/git.git 


$ cd git/contrib/fast-import 





在 这 个 fast-import 






































仓 


Er 





目录 下 ， 应 该 有 














$ export P4PORT=public.perforce.com:1666 


运行 git-p4 clone f 








目标 路 径 : 











A 


令 将 从 Perforce 服务 器 导入 Jam 项 目 ， 我 们 需 
































$ git-p4 clone //public/jam/src@all /opt/p4import 


Importing from //public/jam/src@all into /opt/p4import 


Reinitialized existing Git repository in /opt/p4import/.git/ 


Import destination: refs/remotes/p4/master 


Importing revision 4409 (100%) 


现在 去 /opt/p4import 





$ git log -2 

















commit 1fd4ec126171790efd2db83548b85b1 bbbc07dc2 


Author: Perforce staff <support@perforce.com> 


Date: Thu Aug 19 10:18:45 2004 -0800 


Drop 'rc3' moniker of jam-2.5. 


the main part of the document. 


Only 16 months later. 


Built new tar/zip balls. 


个 叫做 git-p4 的 Python 可 执行 
具 该 导入 才能 正常 进行 。 例 如 ， 你 要 从 Perforce 公共 代码 仓库 (译注 : 
官方 提供 的 代码 寄存 服务 ) 导入 Jam 




















净 的 躺 在 新 的 Git 服务 器 里 了 。 
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LIH 














程 。 为 了 设 定 客户 端 ， 我 们 要 把 PAPORI 






































Folded rc2 and rc3 RELNOTES into 


[git-p4: depot-paths = "//public/jam/src/": change = 4409] 
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BIAS © ERLE DWE Python 和 pa T 





同时 也 附带 了 一 个 Perforce 导入 脚本 ， 








Perforce Public Depot，Perforce 














[ 环境 变量 export 到 Perforce 














人 
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GE 


仓库 和 项 








的 路 径 以 及 











导入 的 
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commit ca8870db541a23ed867f38847eda65bf4363371d 
Author: Richard Geiger <rmg@perforce.com> 
Date: Tue Apr 22 20:51:34 2003 -0800 
Update derived jamgram.c 
[git-p4: depot-paths = "//public/jam/src/": change = 3108] 
ee commit 里 都 有 一 个 git-p4 标识 符 。 这 个 标识 符 可 以 保留 ， 以 防 以 后 需要 引用 Perforce 的 修改 版 
。 然 而 ， 如 果 想 删除 这 些 标识 符 ， 现 在 正 是 时 候 一 一 在 开启 新 仓库 之 前 。 可 以 通过 git filter-branch 来 批 
ee 文 些 标识 符 : 








$ git filter-branch --msg-filter ' 
sed -e "/^N[git-p4:/d" 
Rewrite lfd4ec126171790efd2db83548b85blbbbcO7dc2 (123/123) 


Ref 'refs/heads/master' was rewritten 

















































































































































































































































































































































































































































































































现在 运行 一 下 sit log， 你 会 发 现 这 些 commit 的 SHA-1 校 验 值 都 发 生 了 改变 ， 而 那些 git-p4 字 串 则 从 提交 
信息 里 消失 了 : 
$ git log -2 
commit l0al6d60cffcal4d454al5c6164378f4082bc5b0 
Author: Perforce staff <support@perforce.com> 
Date: Thu Aug 19 10:18:45 2004 -0800 
Drop 'rc3' moniker of jam-2.5. Folded rc2 and rc3 RELNOTES into 
the main part of the document. Built new tar/zip balls. 
Only 16 months later. 
commit 2b6c6db311dd76c34c66ec1c40a49405e6b527b2 
Author: Richard Geiger <rmg@perforce.com> 
Date: Tue Apr 22 20:51:34 2003 -0800 
Update derived jamgram.c 
至 此 导入 已 经 完成 ， 可 以 开始 向 新 的 Git 服务 器 推送 了 。 
8.2.4 自 定 导 入 脚本 
如 果 先 前 的 系统 不 是 Subversion 或 Perforce 之 一 ， 先 上 网 找 一 下 有 没有 与 之 对 应 的 导入 脚本 一 一 导入 
CVS, Clear Case, Visual Source Safe, B 至 存档 目录 的 导入 及 本 已 经 存在 ° 假如 这 些 工 具 都 不 适 j, 或 对 
使 用 的 工具 很 少见 ， 抑 或 你 需要 导入 过 程 具有 更 多 可 制定 性 ， 则 应 该 使 用 sit fast-import。 该 命令 从 标准 输入 
读 取 简单 的 指令 来 写 入 具体 的 Git 数据 。 这 样 创建 Git 对 象 比 运行 纯 Git 命令 或 者 手动 写 对 象 要 简单 的 多 
更 多 相关 内 容 见 第 九 章 ) 。 通 过 它 ， 你 可 以 编写 一 个 导入 脚本 来 从 导入 源 读 取 必 要 的 信息 ， 同 时 在 标准 输出 
接 输 出 相关 指示 。 你 可 以 运行 该 脚本 并 把 它 的 输出 管道 连接 到 git fast-import ° 
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下 面 演示 一 下 如 何 编写 一 个 简单 的 导入 脚本 。 假 设 你 在 进行 一 项 工作 ， 按时 通过 把 工作 目录 复制 为 以 时 
HÆR back vv ww nb 命名 的 目录 来 进行 备份 ， 现 在 你 需要 把 它们 导入 Git 。 目 录 结 构 如 下 
$ 1s /opt/import from 
back 2009 01 02 
back 2009 01 04 
back 2009 01 14 
back 2009 02 03 
current 
为 了 导入 到 一 个 Git 目录 ， 我 们 首先 回顾 一 下 Git 储存 数据 的 方式 。 你 可 能 还 记得 ，Git 本 质 上 是 一 个 
commit 对 象 的 链表 ， 每 一 个 对 象 指向 一 个 内 容 的 快照 。 而 这 里 需要 做 的 工作 就 是 告诉 fast-import 内 容 快照 的 
ME, IFAN commit 数据 指向 它们 ， 以 及 它们 的 顺序 。 我 们 采取 一 次 处 理 一 个 快照 的 策略 ， 为 每 一 个 内 容 
目录 建立 对 应 的 commit ， 每 一 个 commit 与 之 前 的 建立 链接 。 
正如 在 第 七 章 “Git 执行 策略 一 例 ” 一 节 中 一 样 ， 我 们 将 使 用 Ruby 来 编写 这 个 脚本 ， 因 为 它 是 我 日 常 使 
的 语言 而 且 阅 读 起 来 简单 一 些 。 你 可 以 用 任何 其 他 熟悉 的 语言 来 重 写 这 个 例 了 已 仅 需 要 把 必要 的 信息 打 
印 到 标准 输出 而 已 。 同 时 ， 如 果 你 在 使 用 Windows， 这 意味 着 你 要 特别 留意 不 要 在 换行 的 时 候 引入 回 车 符 ( 译 
注 : carriage returns，Windows 换 行 时 加 入 的 符号 ， 通 常 说 的 ) “一 一 Git 的 fast-import 对 仅 使 用 换行 符 
(LE) 而 非 Windows 的 回 车 符 (CRLF) 要 求 非常 严格 。 
首先 ， 进 入 目标 目录 并 且 找 到 所 有 子 目 录 ， 每 一 个 子 目 录 将 作为 一 个 快照 被 导入 为 一 个 comit 。 我 们 将 依 
次 进入 每 一 个 子 目录 并 打印 所 需 的 命令 来 导出 它们 。 脚 本 的 主 循环 大 致 是 这 样 : 
last mark = nil 
# 循环 遍历 所 有 目录 
Dir.chdir(ARGV[0]) do 
Dir.glob("*").each do |dir| 
next if File.file?(dir) 
# 进入 目标 目录 
Dir.chdir(dir) do 
last mark = print export(dir, last mark) 
end 
end 
end 
我 们 在 每 一 个 目录 里 运行 print exor ， 它 会 取出 上 一 个 快照 的 索引 和 标记 并 返回 本 次 快照 的 索引 和 标记 ; 
此 我 们 就 可 以 正确 的 把 二 者 连接 起 来 。“ 标 记 (mark) ” 是 fast-import 中 对 commit 标识 符 的 叫 法 ; 在 创 
建 commit 的 同时 ， 我 们 逐一 赋予 一 个 标记 以 便 以 后 在 把 它 连 接 到 其 他 commit 时 使 用 。 因 此 ， 在 print_export 
方法 中 要 做 的 第 一 件 事 就 是 根据 目录 名 生成 一 个 标记 : 
mark = convert dir to mark(dir) 
实现 该 函数 的 方法 是 建立 一 个 目录 的 数组 序列 并 使 用 数组 的 索引 值 作为 标记 ， 因 为 标记 必须 是 一 个 整数 。 这 
































个 方法 大 致 是 这 样 的 : 
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$marks - [] 
def convert dir to mark(dir) 
if !$marks.include?(dir) 
$marks «« dir 
end 
($marks.index(dir) + 1).to s 


end 
























































有 了 整数 来 代表 每 个 commit， 我 们 现在 需要 提交 附加 信息 中 的 日 期 。 由 于 日 期 是 用 目录 名 表示 的 ， 我 们 就 
从 中 解析 出 来 。print_export 文件 的 下 一 行将 是 : 
















































































date = convert dir to date(dir) 


而 convert dir to date 则 定义 为 


def convert dir to date(dir) 
if dir -- 'current' 
return Time.now().to i 
else 
dir = dir.gsub('back ', '') 
(year, month, day) = dir.split('_') 


return Time.local(year, month, day).to i 

















































































































end 
end 

已 为 每 个 目录 返回 一 个 整 型 值 。 提 交 附 加 信息 里 最 后 一 项 所 需 的 是 提交 者 数据 ， 我 们 在 一 个 全 局 变量 中 直接 
定义 之 
$author = 'Scott Chacon <schacon@example.com>' 






































我 们 差不多 可 以 开始 为 导入 脚本 输出 提交 数据 了 。 第 一 项 信息 指明 我 们 定义 的 是 一 个 commit 对 象 以 及 它 所 
在 的 分 支 ， 随 后 是 我 们 生成 的 标记 ， 提 交 者 信息 以 及 提交 备注 ， 然 后 是 前 一 个 commit 的 索引 ， 如 果 有 的 话 。 
代码 大 致 这 样 : 











































































































# 打印 导入 所 需 的 信息 

puts 'commit refs/heads/master' 

puts ‘mark :' + mark 

puts "committer #{$author} #{date} -0700" 
export data('imported from ' + dir) 


puts 'from :' + last mark if last mark 



























































时 区 (一 0700) 处 于 简化 目的 使 用 硬 
区 。 提交 备注 必须 以 特定 格式 给 出 : 

















4 码 。 如 果 是 从 其 他 版 本 控制 系统 导入 ， 则 必须 以 变量 的 形式 指明 时 
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data (size)\n(contents) 











该 格式 包含 了 单词 data， 所 读 取 数 据 的 大 小 ， 









































个 换行 符 ， 最 后 是 数据 本 身 








候 要 用 到 相同 的 格式 ， 我 们 写 一 个 辅助 方法 ，export_data: 




















def export data(string) 














print "data #{string.size}\n#{string}" 
end 
唯一 剩 下 的 就 是 每 一 个 快照 的 内 容 了 。 这 简单 的 很 ， 









































令 ， 随 后 是 目录 中 每 个 文件 的 内 容 。 














puts 'deleteall' 
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。 由 于 随后 指明 文件 内 容 的 时 




















为 为 它们 分 别处 了 
































Git 会 正确 的 记录 每 一 个 快照 : 











Dir.glob("**/*").each do |file| next if !File.file?(file) 


inline data(file) 


end 

















注意 : 由 于 很 多 系统 


Ez 























次 提交 获取 一 个 命令 来 指出 哪些 文 伯 




















l DUM 26 H 








FEE a 


这 项 数据 ， 不 过 























每 次 修订 看 作 一 个 
被 添 加， 删除 或 者 修改 过 ， 以 及 修改 的 内 容 。 我 们 将 需要 计 和 介 
该 做 法 要 复杂 很 多 一 一 还 如 不 直接 把 所 有 数 
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| 
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commit 到 另 一 个 commit 的 变化 量 ， 











一 你 可 以 输出 deleeall 命 
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假如 前 面 这 个 方法 更 适用 于 你 的 数据 ， 参 考 fast-import 的 man 帮助 页 面 来 了 解 如 何以 这 种 方式 提供 数据 。 



































列举 新 文件 内 容 或 者 指明 带 有 新 内 容 的 已 修改 文件 














M 644 inline path/to/file 
data (size) 
(file contents) 















































这 里 ，644 是 权限 模式 (加 入 有 可 执行 文件 ， 
之 后 立即 列 出 文件 的 内 容 。 我 们 的 inline_data 方法 大 致 是 : 

















def inline data(file, code = 'M', mode = '644') 


content - File.read(file) 


puts "#{code} #{mode} inline #{file}" 


export data(content) 


end 














我 们 重用 了 前 面 定义 过 的 export 


























的 格式 如 下 : 





jua 








需要 探测 之 并 设 定 为 755) 

















data, 大 为 这 











BF 


z 















































最 后 一 项 工作 是 返回 当前 的 标记 











return mark 
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指明 提交 注释 的 格式 如 














LME 下 次 循环 











的 使 用 





o 

















， 而 inline PARA JEA T 








fast-import 也 可 以 依据 每 
快照 之 间 的 
BA Git 然 它 自 己 搞 清楚 。 
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H 
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注意 : 如 果 你 在 用 Windows， 一 定 记得 添加 一 项 额外 的 步 又。 前 面 提 过 ，Windows 使 用 CRLF 作为 换行 字符 
而 Git fast-import 只 接受 LF。 为 了 绕 开 这 个 问题 来 满足 git fast-import， 你 需要 让 ruby 用 LF 取代 
CRL 



























































Ij 


$stdout.binmode 





Z 


搞定 了 。 现 在 运行 该 脚本 ， 你 将 得 到 如 下 内 容 : 











$ ruby import.rb /opt/import_from 
commit refs/heads/master 

mark :1 

committer Scott Chacon <schacon@geemail.com> 1230883200 -0700 
data 29 

imported from back 2009 01 02deleteall 
M 644 inline file.rb 

data 12 

version two 

commit refs/heads/master 

mark :2 


committer Scott Chacon <schacon@geemail.com> 1231056000 -0700 


data 29 

imported from back 2009 01 04from :1 
deleteall 

M 644 inline file.rb 

data 14 


version three 
M 644 inline new.rb 
data 16 


new version one 


(o) 



































要 运行 导入 脚本 ， 在 需要 导入 的 目录 把 该 内 容 用 
fT sit init 作为 开头 ， 然 后 运行 该 脚本 ; 


me 
wig 





FE [A] Zl] git fast-import。 你 可 以 建立 一 个 空 目录 然后 运 















































tt 




















$ git init 
Initialized empty Git repository in /opt/import to/.git/ 
$ ruby import.rb /opt/import from | git fast-import 


git-fast-import statistics: 


Alloc'd objects: 5000 

Total objects: 18 ( 1 duplicates ) 
blobs TEC 1 duplicates 0 deltas) 
trees 6€ 0 duplicates 1 deltas) 
commits: 5 ( 0 duplicates 0 deltas) 
tags 0€ 0 duplicates 0 deltas) 

Total branches: 1€ 1 loads ) 
marks: 1024 ( 5 unique ) 
atoms: 3 

Memory total: 2255 KiB 
pools: 2098 KiB 
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$83 Git 与 其 他 系统 
objects: 156 KiB 
pack report: getpagesize() = 4096 
pack_report: core.packedGitWindowSize = 33554432 
pack_report: core.packedGitLimit = 268435456 
pack_report: pack_used_ctr = 9 
pack_report: pack_mmap_calls = 5 
pack report: pack open windows z 15A 1 
pack report: pack mapped = 1356 / 1356 
A. Lp. mz BB 一 S A. LA " se 
你 会 发 现 ， 在 它 成 功 执行 完毕 以 后 ， 会 给 出 一 堆 有 关 已 完 
据 ， 包 含 了 18 个 对 象 。 现 在 可 以 运行 zit log 来 检视 新 的 历 








$ git log -2 

commit 10bfe7d22cel5ee25b60a824c8982157ca593d41 
Author: Scott Chacon <schacon@example.com> 
Date: Sun May 3 12:57:39 2009 -0700 


imported from current 


commit 7e519590de754d079dd73b44d695a42c9d2df452 
Author: Scott Chacon <schacon@example.com> 


Date: Tue Feb 3 01:00:00 2009 -0700 


imported from back_2009_02_03 
































就 它 了 AFA 




















| 





ls 
git reset --hard master 

HEAD is now at 10bfe7d imported from current 
1s 
file.rb 





lib 














整洁 的 Git 仓库 。 需 要 注意 的 是 此 时 没有 
王 何 文件 。 要 获取 它们 ， 你 得 转 到 master 分 支 的 所 在 : 











[ 作 的 数据 。 上 例 在 一 个 分 支 导 入 了 5 次 提交 数 




















任何 内 容 被 检 H 








EE 




































































fast-import 还 可 以 做 更 















































处 理 不 同 的 文件 模式 ， 二 进 
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Bp, SHON 

















刚 开 始 当 前 目录 里 没有 
， 标 签 ， 进 展 标识 等 等 。 

















































































































些 更 加 复杂 的 实例 可 以 在 Git 源码 的 contib/fast-import 目录 里 找到 ; 其 中 较为 出 众 的 是 前 
脚本 。 
8.3 总 结 

现在 的 你 应 该 掌握 了 在 Subversion 上 使 用 Git 以 及 把 几乎 任何 先 存 仓库 无 损失 的 导入 为 Gi 
章 将 介绍 Git 内 部 的 原始 数据 格式 ， 从 而 是 使 你 能 亲手 锻造 其 中 的 每 一 个 字 节 ， 如 果 必 要 的 话 
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面 提 过 的 git-p4 





poe 


Git 内 部 原理 











































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































不 管 你 是 从 前 面 的 村 接 跳 到 了 本 章 ， 还 是 读 完了 其 余 各 到 这 ， 你 都 将 在 本 章 见 识 Git 的 内 部 工 
作 原 理 和 实现 方式 。 P Git 的 用 处 和 强大 是 非常 重要 的 ， 不 过 也 有 人 认为 这 
些 内 容 对 于 初学 者 来 说 可 能 难以 理解 且 过 于 复杂 。 正 因 如 此 我 把 这 部 分 内 容 放 在 最 后 一 章 ， 你 在 学 习 过 程 中 可 
以 先 阅读 这 部 分 ， 也 可 以 晚点 阅读 这 部 分 ， 这 完全 取决 于 你 自己 。 

既然 已 经 读 到 这 了 ， 束 让 我 们 开始 吧 。 首 先 要 和 弄 明 白 一 点 ， 从 根本 上 来 讲 Git 是 一 套 内 容 寻 址 (content- 
addressable) 文件 系统 ， 在 此 之 上 提供 了 一 个 VCS 用 户 界面 。 马 上 你 就 会 学 到 这 意味 着 什么 。 

早期 的 Git (主要 是 1.5 之 前 版 本 ) 的 用 户 界面 要 比 现在 复杂 得 多 ， 这 是 因为 它 更 侧重 于 成 为 文件 系统 而 
不 是 一 套 更 精致 的 VCS 。 最 近 几 年 改进 了 Ul 从 而 使 它 跟 其 他 任何 系统 一 样 清晰 易 用 。 即 便 如 此 ， 还 是 经 常 
会 有 SPREE ET Git AY UI 复杂 又 难 学 。 

内 容 寻 址 文件 系统 这 一 层 相 当 酷 ， 在 本 章 中 我 会 先 讲解 这 部 分 。 随 后 你 会 学 到 传输 机 制 和 最 终 要 使 用 的 各 种 
库 管 理 任务 。 

9.1 底层 命令 (Plumbing) 和 高 层 命 令 (Porcelain) 

本 书 讲解 了 使 用 checkout, branch, remote 等 共 约 30 个 Git 命令 。 然 而 由 于 Git 一 开始 被 设计 成 供 
vcs 使 用 的 工具 集 而 不 是 一 整套 用 户 友 好 的 VCS， 它 还 包含 了 许多 底层 命令 ， 这 些 命令 用 于 以 UNIX 风格 
使 用 或 由 脚本 调用 。 这 些 命令 一 般 被 称 为 "plumbing" 命令 (底层 命令 ) 他 的 更 友好 的 命令 则 被 称 为 

"porcelain" 命令 (高 层 命 D) o 

本 书 前 八 章 主要 专门 讨论 高 层 命令 。 本 章 将 主要 讨论 底层 命令 以 理解 Git 的 内 部 工作 机 制 、 演 示 Git 如 何 
及 为 何 要 以 这 种 方式 工作 。 这 些 命令 主要 不 是 用 来 从 命令 行 手 工 使 用 的 ， 更 多 的 是 用 来 为 其 他 工具 和 自 定 义 脚 
本 服务 的 。 

当 你 在 一 个 新 目录 或 已 有 目录 内 执行 git init Bf, Git 会 创建 一 个 .git 目录 ， 几 乎 所 有 Git 存储 和 操作 
的 内 容 都 位 于 该 目录 下 。 如 果 你 要 备份 或 复制 一 个 库 ， 基 本 上 将 这 一 目录 找 贝 至 其 他 地 方 就 可 以 了 。 本 章 基 本 
上 都 讨论 该 目录 下 的 内 容 。 该 目录 结构 如 下 : 
$ 1s 
HEAD 
branches/ 
config 
description 
hooks/ 
index 
info/ 


199 
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objects/ 
refs/ 

该 目录 下 有 可 能 还 有 其 他 文件 ， 但 这 是 一 个 全 新 的 sit init 生成 的 库 ， 所 以 默认 情况 下 这 些 就 是 你 能 看 到 
的 结构 。 新 版 本 的 Git 不 再 使 用 branches 目录 ，description 文件 仅 供 GitWeb 程序 使 用 ， 所 以 不 用 关心 这 些 
内 容 。config 文件 包含 了 项 目 特有 的 配置 选项 ，infe 目录 保存 了 一 份 不 希望 在 .gitignore 文件 中 管理 的 忽略 
模式 (ignored patterns) 的 全 局 可 执行 文件 。hooks 目录 包 住 了 第 六 章 详细 介绍 了 的 客户 端 或 服务 端 钩子 脚 
本 。 

另外 还 有 四 个 重要 的 文件 或 目录 : HEAD 及 index 文件 ，objects 及 refs 目录 。 这 些 是 Git 的 核心 部 分 。objects 
目录 存储 所 有 数据 内 容 ，refs 目录 存储 指向 数据 (分 支 ) 的 提交 对 象 的 指针 ，HEAp 文件 指向 当前 分 支 ，index 
文件 保存 了 和 暂 存 区 域 信 息 。 马 上 你 将 详细 了 解 Git 是 如 何 操纵 这 些 内 容 的 。 
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Git 是 一 套 内 容 寻 址 文件 系统 。 很 不 错 。 不 过 这 是 什么 意思 呢 ? 

这 种 说 法 的 意思 是 ， 从 内 部 来 看 ，Git 是 简单 的 key-value 数据 存储 。 它 允许 插入 任意 类 型 的 内 容 ， 并 会 
返回 一 个 键 值 ， 通 过 该 键 值 可 以 在 任何 时 候 再 取出 该 内 容 。 可 以 通过 廉 层 命令 hash-object 来 示范 这 点 ， 传 一 
些 数据 给 该 命令 ， 它 会 将 数据 保存 在 .git 目录 并 返回 表示 这 些 数据 的 键 值 。 首 先 初 使 化 一 个 Git 仓库 并 确认 
objects 目录 是 空 的 : 





























$ mkdir test 
$ cd test 
$ git init 


Initialized empty Git repository in /tmp/test/.git/ 


$ find .git/objects 
.git/objects 
.git/objects/info 
.git/objects/pack 


$ find .git/objects -type f 


$ 


Git 初始 化 了 objects 
件 。 我 们 往 这 个 Git 数据 库 里 存储 一 些 文本 : 























ok, 





ARN ES E 

















录 下 创建 了 pack 和 info F 




















¥ 























录 下 没有 其 他 常规 文 




















$ echo 'test content' | git hash-object -w --stdin 
d670460b4b4aece5915caf5c68d12f560a9fe3e4 


参数 W 指示 hash-object 


标准 输入 设备 (stdin) 
为 40 个 字符 
校 验 和 。 现 在 可 以 查 


E 

















i 








a 
Hp 


令 存储 BS 

















来 读 








$ find .git/objects -type f 
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 
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的 校 验 和 。 这 是 个 SHA-] 














到 cit 已 经 存储 了 数 和 


ET 





取 内 容 ， 若 不 指定 这 个 参数 则 需 指定 一 个 要 存储 的 文人 





F 的 路 径 。 该 命令 输出 长 


E) 对 象 ， 若 不 指定 这 个 参数 该 命令 仅仅 返回 键 值 。--stdin 指定 从 





度 
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Hh 


~ 





i m 


直 为 要 存储 的 数据 加 上 你 马上 会 ] 





























解 到 的 一 种 头 信 


A 
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可 以 在 














个 字符 为 文件 全 


通过 cat-file 


























objects 目 








A 


REEF A 























录 下 看 到 一 个 文人 
得 该 内 容 与 头 信息 的 SHA-1 校 输 和 ， 创 建 
KT 
命令 可 以 将 数据 内 容 取 回 。 
输出 数据 内 容 的 类 型 : 








F。 这 便 是 Git 存储 数据 内 容 的 方式 




















该 校 验 和 


个 字符 为 名 








前 


























$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4 


test content 


































































































可 以 往 Git 中 添加 更 多 内 容 并 取 回 了 。 也 可 以 
制 。 首 先 ， 创 建 一 个 新 文件 ， 并 把 文件 内 容 存储 到 数据 库 
$ echo 'version 1' > test.txt 
$ git hash-object -w test.txt 


























83baae61804e65cc73a7201a7252750c76066a30 





ay 











os ax xt 

















$ echo 'version 2' 


$ git hash-object 














写 入 一 些 新 内 


SEE 
Ye WESIE et 


BS 












































Tr 





lf7a7a472abf3dd9643fd615f6da379c4acb3e3a 











数据 库 中 已 经 将 文件 的 























$ find .git/objects -type f 
.git/objects/1f/TaT7aAT2abf3dd9643fd615f6da379c4acb3e3a 
.git/objects/83/baae61804e65cc73a7201a72527750c76066a30 
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 














了 将 文件 恢复 











到 第 一 个 版 





vt 


再 次 保存 : 





该 命令 是 查看 Git 对 象 的 瑞 


接 添加 文件 。 比 方 说 可 以 对 一 个 文件 进行 





i 个 新 版 本 连同 一 开始 的 内 容 保存 下 





A 


$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt 


$ cat test.txt 


version 1 


或 恢复 到 第 二 


个 版 本 : 


$ git cat-file -p lf7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt 


$ cat test.txt 


version 2 
































称 的 子 

















K, 











为 每 份 内 容 生成 一 个 文 伯 
以 ( 校 验 和 ) RIF 38 


9.2 节 Git 对 象 


T 





， 取 


军刀 (EA -» 参数 可 以 让 该 命令 




















的 版 本 控 
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需要 记 住 的 是 几 个 版 本 的 文件 SHA-1 值 可 能 与 实际 的 值 不 同 ， 其 次 ， 存 储 的 并 不 是 文件 名 而 仅仅 是 文件 内 
容 。 这 种 对 象 类 型 称 为 blob 。 通 过 传递 SHA-1 值 给 cat-file -t 命令 可 以 让 Git 返回 任何 对 象 的 类 型 ; 

































































$ git cat-file -t lf7a7a472abf3dd9643fd615f6da379c4acb3e3a 
blob 


9.2.1 tree (M) 对 象 


接 下 去 来 看 tree WR, tree 对 象 可 以 存储 文件 名 ， 同 时 也 允许 存储 一 组 文件 。Git 以 一 种 类 似 UNIX 文 
和 系统 但 更 简单 的 方式 来 存储 内 容 。 所 有 内 容 以 tree 或 blob 对 象 存储 ， 其 中 tree 对 象 对 应 于 UNIX 中 的 
目录 ，blob 对 象 则 大 致 对 应 于 inodes 或 文件 内 容 。 一 个 单独 的 tree 对 象 包含 一 条 或 多 条 tree WR, 
一 条 记录 含有 一 个 指向 blob RF tree 对 象 的 SHA-1 指针 ， 并 附 有 该 对 象 的 权限 模式 mode)、 类 型 和 文件 
名 信息 。 以 simplegit 项 目 为 例 ， 最 新 的 tree 可 能 是 这 个 样子 ; 











TF 









































































































































$ git cat-file -p master^(tree) 


100644 blob a906cb2a4a904a152e80877d4088654daad0c859 README 
100644 blob 8f94139338f9404f26296befa88755fc2598c289 Rakefile 
040000 tree 99fla6d12cb4b6f19c8655fca46c3ecf317074e0 lib 
































master tree 表示 branch 分 支 上 最 新 提交 指向 的 tree 对 象 。 请 注意 ne 子 目 录 并 非 一 个 blob WR, mj 
一 个 指向 别 一 个 tree 对 象 的 指针 : 











$ git cat-file -p 99fla6d12cb4b6f19c8655fca46c3ecf317074e0 
100644 blob 47c6340d6459e05787£644c2447d2595f5d3a54b simplegit.rb 

















从 概念 上 来 讲 ，Git 保存 的 数据 如 图 9.1 所 示 。 


README ne ida lib 


SJE DJ 


simplegit.rb 








E 9.1: Git 对 象 模型 的 简化 版 





Tar 




















你 可 以 自己 创建 tree 。 通 常 Git 根据 你 的 暂 存 区 域 或 index 来 创建 并 写 入 一 个 tree 。 因 此 要 创建 一 
个 tree 对 象 的 话 首先 要 通过 将 一 些 文件 暂 存 从 而 创建 一 个 index 。 可 以 使 用 plumbing 命令 update-index 为 
一 个 单独 文件 test.txt 文件 的 第 一 个 版 本 一 一 创建 一 个 index 。 通 过 该 命令 人 为 的 将 test.txt 
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文件 的 首 个 版 本 加 入 到 了 一 个 新 的 暂 存 区 域 中 。 由 于 该 文件 原先 并 不 在 暂 存 区 域 中 (甚至 就 连 暂 存 区 域 也 还 
没 被 创建 出 来 呢 ) ， qj 页 传 入 --add 人 参数; 1 于 要 添加 的 文件 不 在 当 前 录 下 而 是 在 数据 库 7 必须 传 入 u 
cacheinfo 参数 。 同 时 指定 了 文件 模式 ，SHA-1 值 和 文件 名 : 







































































































































































$ git update-index --add --cacheinfo 100644 N 
83baae61804e65cc73a7201a7252750c76066a30 test.txt 






























































在 本 例 中 ， 指 定 了 文件 模式 为 100644， 表 明 这 是 一 个 普通 文件 。 其 他 可 用 的 模式 有 : 100755 表示 可 执行 文 
F, 120000 表示 符号 链接 。 文 件 模式 是 从 常规 的 UNIX 文件 模式 中 参考 来 的 ， 但 是 没有 那么 灵活 E= 
种 模式 仅 对 Git 中 的 文件 (blobs) 有 效 (虽然 也 有 其 他 模式 用 于 目录 和 子 模块 )。 

现在 可 以 用 write-tree 命令 将 和 暂 存 区 域 的 内 容 写 到 一 个 tree 对 象 了 。 无 需 w 参数 如 果 目 标 tree 
不 存在 ， 调 用 write-tree 会 自动 根据 index 状态 创建 一 个 tree 对 象 。 
























































Lr. 
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Lr 



















































































































































































$ git write-tree 

d8329fc1cc938780ffdd9f94e0d364e0ea74f579 

$ git cat-file -p d8329fcl1cc938780ffdd9f94e0d364e0ea74f579 

100644 blob 83baae61804e65cc73a7201a7252750c76066a30 test.txt 











可 以 这 样 验证 这 和 胡 











ay 


实 是 一 个 tree WR: 








$ git cat-file -t d8329fclcc938780ffdd9f94e0d364e0ea74f579 


tree 

















再 根据 test.txt 的 第 二 个 版 本 以 及 一 个 新 文件 创建 一 个 新 tree IR: 











$ echo 'new file' > new.txt 
$ git update-index test.txt 
$ git update-index --add new.txt 

















这 时 暂 存 区 域 中 包含 了 test.txt 的 新 版 本 及 一 个 新 文件 new.txt ME (ED 该 tree WR (将 暂 存 区 
域 或 index 状态 写 入 到 一 个 tree WR), ， 然 后 瞧 瞧 它 的 样子 : 

















x 









































$ git write-tree 
0155eb4229851634a0f03eb265b69f5a2d56f341 
$ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341 









































































































































































































































100644 blob fa49b077972391ad58037050f2a'75f74e3671e92 new. txt 
100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a (Ce Stent xt 

请 注意 该 tree 对 象 包含 了 两 个 文件 记录 ,， 且 test.txt 的 SHA 值 是 早先 值 的 “第 二 版 ” Qf7a7a)。 来 点 
更 有 趣 的 ， 你 将 把 第 一 个 tree 对象 作为 一 个 子 目录 加 进 该 tree 中 。 可 以 用 read-tree 命令 将 tree WRF 
到 T E [x Jak E o 车 这 时 ， iH fi 个 --prefix 参数 给 H read-tree, 将 个 已 有 的 tree 对 象 作为 一 个 子 tree 
读 到 暂 存 区 域 中 : 
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iss 


$ git read-tree --prefix=bak d8329fcl1cc938780ffdd9f94e0d364e0ea74f579 
$ git write-tree 

3c4e9cd789d88d84d89c1073707c3585e41b0e614 

$ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614 


040000 tree d8329fcl1cc938780ffdd9f94e0d364e0ea74f579 bak 
100644 blob fa49b077972391ad58037050f2a'75f74e3671e92 new. txt 
100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test. txt 





























如 果 从 刚 写 入 的 新 tree 对 象 创建 一 个 工作 目录 ， 将 得 到 位 了 









































录 ， 该 子 目录 包含 了 test.txt 文件 的 第 一 个 版 本 。 可 以 将 
所 示 的 检 











L^ o 








TE 








图 9.2: 当前 Git 数据 的 内 容 结 构 


9.2.2 commit (提交 ) 对 象 





你 现在 有 三 个 tree 对 象 ， 它 们 指向 了 你 要 跟踪 的 项 目的 不 同 快 和 














个 文人 









































个 SHA-1 值 以 获得 这 些 快照 。 你 也 没有 关于 谁 、 何 时 以 及 为 何 保存 了 这 些 快 照 的 信 ， 
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IU 








Xil 

2 | 
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> ui 











p 
al 
E 
m 
Flt 


从 你 写 的 第 一 个 tree 开始 : 


$ echo 'first commit' | git commit-tree d8329f 
fdfA4fc3344e67ab068f836878b6c4951e3b15f3d 


通过 cat-file 查看 这 个 新 commit 对 象 : 


























$ git cat-file -p fdf4fc3 

tree d8329fclcc938780ffdd9f94e0d364e0ea74f579 

author Scott Chacon <schacon@gmail.com> 1243040974 -0700 
committer Scott Chacon <schacon@gmail.com> 1243040974 -0700 


first commit 
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d8329f 

tree 
83baae 
"version 1" 
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F 和 一 个 名 为 bak 的 子 
用 来 包含 这 些 内 容 的 数据 想象 成 如 图 9.2 





F 


前 的 问题 依然 存在 : 必须 记 往 三 
E o commit 对 象 为 你 保存 




















commit XR, H commit-tree 命令 ， 指 定 一 个 tree 的 SHA-1， 如 果 有 任何 前 继 提 交 对 象 ， 


Scott Chacon Pro Git 9.27 Git WA 












































commit 对 象 有 格式 很 简单 ， 指 明了 该 时 间 点 项 目 快照 的 顶层 树 对 象 、 作 者 /提交 者 信息 (从 Git 设 理发 店 
的 user.name 和 user.email! 获得 ) 以 及 当前 时 间 惟 E ES 个 空 行 ， 以 及 提交 注释 信息 j 
接着 再 写 入 另外 两 个 comit 对 象 ， 每 一 个 都 指定 其 之 前 的 那个 comit 对 象 : 





















































































































































$ echo 'second commit' | git commit-tree 0155eb -p fdf4fc3 
cac0cab538b970a37eale769cbbde608743bc96d 
$ echo 'third commit' | git commit-tree 3c4e9c -p cacOcab 


la410efbd13591db07496601ebc7a059dd55cfe9 




















每 一 个 commit 对 象 都 指向 了 你 创建 的 树 对 象 快照 。 出 平 意料 的 是 ， 现 在 已 经 有 了 真实 的 Git 历史 了 ， 所 
以 如 果 运 行 sit tos 命令 并 指定 最 后 那个 commit 对 象 的 SHA-1 便 可 以 查看 历史 : 


































































































$ git log --stat la410e 
commit la410efbd13591db07496601ebc7a059dd55cfe9 
Author: Scott Chacon <schacon@gmail.com> 


Date: Fri May 22 18:15:24 2009 -0700 


third commit 


bak/test.txt | T+ 
1 files changed, 1 insertions(+), 0 deletions(-) 


commit cac0cab538b970a37eale769cbbde608743bc96d 
Author: Scott Chacon <schacon@gmail.com> 


Date: Fri May 22 18:14:29 2009 -0700 
second commit 

new.txt | Lt 

test.txt | 2 += 

2 files changed, 2 insertions(+), 1 deletions(-) 
commit fdf4fc3344e67ab068f836878b6c4951e3b15f3d 
Author: Scott Chacon <schacon@gmail.com> 

Date: Fri May 22 18:09:34 2009 -0700 


first commit 


test.txt | Joss 
1 files changed, 1 insertions(+), 0 deletions(-) 
































Lhe o 你 刚刚 通过 使 用 低级 操作 而 不 是 那些 普通 命令 创建 了 一 个 Git 历史 。 这 基本 上 就 是 运行 git aaa 和 
git commit 命令 时 Git 进行 的 工作 一 一 保存 修改 了 的 文件 的 blob， 更 新 索引 ,创建 tree 对 象 ， 最 后 创建 
commit XR, XÆ commit 对 象 指 向 了 顶层 tree 对 象 以 及 先前 的 commit 对 象 。 这 三 类 Git HR 一 一 
blob, tree 以 及 tree 都 各 自 以 文件 的 方式 保存 在 .git/objects 目录 下 。 以 下 所 列 是 目前 为 止 样 例 中 的 
所 有 对 象 ， 每 个 对 象 后 面 的 注释 里 标明 了 它们 保存 的 内 容 : 
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Z 

































































$ find .git/objects -type f 
.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2 
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"n 


.git/objects/1la/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3 
.git/objects/1f/TaTa472abf3dd9643fd615f6da379c4acb3e3a # test.txt v2 
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3 
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt vl 
.git/objects/ca/cO0cab538b970a37eale769cbbde608743bc96d # commit 2 
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # 'test content' 
.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1 
.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new. txt 
.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3bl5f3d # commit 1 








如 有 果 你 按照 以 上 描述 进行 了 操作 ， 可 以 得 到 如 图 9.3 所 示 的 对 象 

















bak 





RI 


















test.txt 


1f7a7a 
"version 2" 
test.txt 





0155eb 
tree 
new.txt 


图 9.3: Git 目录 下 的 所 有 对 象 


9.2.3 对 象 存 储 


之 前 我 提 到 当 存 储 数 据 内 容 时 ， 同 时 会 有 一 个 文件 头 被 存储 起 来 。 我 们 花 些 时 间 来 看 看 Git 是 如 何 存储 对 
你 将 看 来 如 何 通过 Ruby 脚本 语言 存储 一 个 blob WR (这 里 以 字符 串 

















象 的 
o (EH irb 命令 进入 Ruby 交互 式 模式 : 


o 
























































$ irb 
>> content = "what is up, doc?" 


=> "what is up, doc?" 

















Git 以 对 象 类 型 为 起 始 内 容 构造 一 个 文件 头 ， 本 例 中 是 一 个 blob。 





长 度 ， 最 后 是 一 个 空 字 节 (null byte): 


>> header = "blob Z(content.length)NO" 
=> "blob 16\000" 














Git 将 文件 头 与 原始 数据 内 容 拼接 起 来 ， 并 计算 拼接 后 的 新 内 容 的 SHA-1 校 验 和 。 可 以 在 Ruby 
require 语句 导入 SHA1 digest 库 ， 然后 调用 Digest::SHAl.hexdigest() 方法 计算 
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添加 一 个 空格 ， 接 着 是 数据 内 容 的 


= 





Scott Chacon Pro Git 





“what is up, doc?” 









































d 








BAY) SHA-1 { 














Scott Chacon Pro Git 


store - header * content 
"blob 16N000what is up, doc?" 
require 'digest/shal' 

true 

shal = Digest::SHAl.hexdigest(store) 


"bd9dbf5aaela3862dd1526723246020206e5fc37 " 
































Git 








HES 








缩 ， 在 Ruby 


缩 : 


zlib 对 数据 内 容 进 行 
Zlib::Deflate.deflate() 对 数据 进行 压 



































require 'zlib' 
true 
zlib content - Zlib::Deflate.deflate(store) 


"x\284K\312\3110R04c(\317H, Q\310, V(-\320QH\3110\266\a\000_\034\a\235" 








后 将 用 zlib 压缩 后 的 内 容 写 入 磁盘 





o 需要 指定 保存 对 象 的 路 径 





























1 可 以 用 zlib 库 来 实现 。 首 先 








9.3 节 Git References 





(SHA-1 值 的 六 












































IR 38 个 字符 作为 文件 名 保存 至 该 














)。 在 Ruby 中 ， 如 果 








子 目 录 不 存在 可 
























































T 





= 


| 建 它 。 接 着 用 File.open 方法 打开 文件 ， 








用 write() 方法 将 之 




















RT 


path = '.git/objects/' + shal[0,2] + '/' + shal[2,38] 

" git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5f£c37" 
require 'fileutils' 

true 

FileUtils.mkdir p(File.dirname(path)) 
" git/objects/bd" 

File.open(path, 'w') ( |f| f.write zlib content ) 


32 











这 就 行 了 一 一 你 已 经 创建 了 一 
类 型 不 同 一 一 除了 字符 审 
任意 内 容 ，commit 和 tree 的 数据 却 是 有 


FH 


正确 的 blob 对 象 。 所 


















































司 定格 式 的 。 








9.3 Git References 











前 

















你 可 以 执行 像 git log 1a410e 
交 ， 这 样 才 能 在 提交 历史 中 找到 这 ! 
你 就 可 以 用 这 些 指针 而 不 是 原来 的 SHA-1 值 去 检索 了 
在 Git ! ， 我 们 称 之 为 “引用 ” references 或 者 refs, 


些 包 含 SHA-1 值 的 文件 。 在 这 个 项 目 里 ， 这 个 


这 样 的 命令 来 查看 完整 的 历史 ， 但 


些 对 象 。 你 需要 一 个 文件 来 用 一 个 简 
































这 
Hj 














o 













































































ix 注 















































$ find .git/refs 
.git/refs 
.git/refs/heads 
.git/refs/tags 


录 还 没 不 包含 任何 文件 ， 





° 不 过 时 


BER 





是 这 样 你 就 要 记得 1a410e 


TN 2$ 


个 字符 作为 子 
DLA FileUtils.mkdir_p() 


压缩 的 内 容 写 入 该 文人 





有 的 Git 对 象 都 以 这 种 方式 存储 ， 
blob, EI commit BK tree 




















H 


可 以 在 





“你 








单 的 名 字 来 记录 这 些 


.git/refs 


TF 


blob 几乎 可 以 是 

















Hl 








A 
Z 





目录 




















惟一 的 区 





x 别 是 


ii 








是 你 最 后 一 次 提 
SHA-1 














， 这 样 




















目录 下 





面 找 到 这 























NIE 

















BEUR XH 








P TRI 





的 结构 : 
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$ find .git/refs -type f 
$ 





























如 果 想 要 创建 一 个 新 的 引用 帮助 你 记 住 最 后 一 次 提交 ， 技 术 上 你 可 以 这 样 做 : 
































$ echo "la410efbd13591db07496601ebc7a059dd55cfe9" > .git/refs/heads/master 









































现在 ， 你 就 可 以 在 Git 命令 中 使 用 你 刚才 创建 的 引用 而 不 是 SHA-1 f 


























$ git log --pretty=oneline master 

la410efbd13591db07496601ebc7a059dd55cfe9 third commit 
cac0cab538b970a37eale769cbbde608743bc96d second commit 
fdf4fc3344e67ab068f836878b6c4951e3bl5f3d first commit 









































LL 














SR, BUNA ARBRE BOR S| CE o IRR SE TSA, Git 提供 了 一 个 安全 的 命令 


update-ref: 























$ git update-ref refs/heads/master la410efbd13591db07496601ebc7a059dd55cfe9 




















基本 上 Git 中 的 一 个 分 支 其 实 就 是 一 个 指向 茶 个 工作 版 本 一 条 HEAD. 记录 的 指针 或 引用 。 你 可 以 用 这 条 命 
令 创建 一 个 指向 第 二 次 提交 的 分 支 ; 





























$ git update-ref refs/heads/test cac0ca 


























羊 你 的 分 支 将 会 只 包含 那 次 提交 以 及 之 前 的 工作 : 











T 





$ git log --pretty-oneline test 
cac0cab538b970a37eale769cbbde608743bc96d second commit 
fdf4fc3344e67ab068f836878b6c4951e3bl5f3d first commit 





DR 


现在 ， 你 的 Git 数据 库 应 该 看 起 来 像 图 9.4 一 档 
每 当 你 执行 zit branch (分 支 名 称 ) 这 样 的 命令 ，Git 基本 上 就 是 执行 update-ref 命令 ， 把 你 现在 所 在 分 文中 
最 后 一 次 提交 的 SHA-1 值 ， 添 加 到 你 要 创建 的 分 支 的 引用 。 








































































































= 

















9.3.1 HEAD 标记 




















现在 的 问题 是 ， 当 你 执行 git branch (分 支 名 称 ) 这 条 命令 的 时 候 ，Git 怎么 知道 最 后 一 次 提交 的 SHA-1 fü 
Up? 答案 就 是 HEAD 文件 。HEAD 文件 是 一 个 指向 你 当前 所 在 分 支 的 引用 标识 符 。 这 样 的 引用 标识 符 一 一 它 看 
起 来 并 不 像 一 个 普通 的 引用 一 一 其 实 并 不 包含 SHA-1 值 ， 而 是 一 个 指向 另外 一 个 引用 的 指针 。 如 果 你 看 一 下 
这 个 文件 ， 通 常 你 将 会 看 到 这 样 的 内 容 ; 













































































































































































H 
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bak 


refs/heads/master new.txt 


test.txt 


e1SSeb test. d] 
ae 


CE 'S3booe 
tree test.txt "version 1" 


E 9.4: 包含 分 支 引 用 的 Git 目录 对 象 








$ cat .git/HEAD 


ref: refs/heads/master 


TEK 


如 果 你 执行 git checkout test, Git 就 会 更 新 这 个 文件 ， 看 起 来 像 这 村 











$ cat .git/HEAD 
ref: refs/heads/test 








当 你 再 执行 git commit 命令 ， 它 就 创建 了 一 个 commit 对 象 ， 把 这 个 commit 对 象 的 父 级 设置 为 HEAD 指向 
的 引用 的 SHA-1 值 。 

你 也 可 以 手动 编辑 这 个 文件 ， 但 是 同样 有 一 个 更 安全 的 方法 可 以 这 样 做 : synmbolic-ref。 你 可 以 用 下 面 这 条 合 
令 读 取 HEAD 的 值 : 


















































> 








a 


















































$ git symbolic-ref HEAD 
refs/heads/master 











你 也 可 以 设置 HEAD 的 值 : 











$ git symbolic-ref HEAD refs/heads/test 
$ cat .git/HEAD 
ref: refs/heads/test 





























但 是 你 不 能 设置 成 refs 以 外 的 形式 : 


$ git symbolic-ref HEAD test 
fatal: Refusing to point HEAD outside of refs/ 


209 





第 9 章 Git 内 部 原理 Scott Chacon Pro Git 


iss 


9.3.2 Tags 












































你 刚刚 已 经 重 温 过 了 Git 的 三 个 主要 对 象 类 型 ， 现 在 这 是 第 四 种 。Tag 对 象 非常 像 一 个 comit 对 象 一 一 
包含 一 个 标签 ， 一 组 数据 ， 一 个 消息 和 一 个 指针 。 最 主要 的 区 别 就 是 Tag 对 象 指向 一 个 comit 而 不 是 一 


















































































































































个 tree。 它 就 像 是 一 个 分 支 引 用 ， 但 是 不 会 变化 一 一 永远 指向 同一 个 commit， 仅 仅 是 提供 一 个 更 加 友好 的 名 
字 。 

正如 我 们 在 第 二 章 所 讨论 的 ，Tag 有 两 种 类 型 : annotated 和 lightweight 。 你 可 以 类 似 下 面 这 样 的 命令 
建立 一 个 lightweight tag: 





$ git update-ref refs/tags/v1.0 cac0cab538b970a37eale769cbbde608743bc96d 

















这 就 是 lightweight tag 的 全 部 一 一 一 个 永远 不 会 发 生变 化 的 分 支 。 annotated tag 要 更 复杂 一 点 。 如 
你 创建 一 个 annotated tag, Git 会 创建 一 个 tas 对 象 ， 然 后 写 入 一 个 指向 指向 它 而 不 是 直接 指向 commit 
的 reference。 你 可 以 这 样 创建 一 个 annotated tag (-a 参数 表明 这 是 一 个 annotated tag) 






















































































$ git tag -a v1.1 la410efbd13591db07496601ebc7a059dd55cfe9 —m 'test tag' 














这 是 所 创建 对 象 的 SHA-1 f 











$ cat .git/refs/tags/vl.l 
9585191f37f7bO0fb9444f35a9bf50del9lbeadc2 





现在 你 可 以 运行 cat-file 命令 检查 这 个 SHA-1 f 





























$ git cat-file -p 9585191f37f7b0fb9444f35a9bf50del9lbeadc2 

object la410efbd13591db07496601ebc7a059dd55cfe9 

type commit 

tag vl.l 

tagger Scott Chacon <schacon@gmail.com> Sat May 23 16:48:58 2009 -0700 


test tag 





























值得 注意 的 是 这 个 对 象 指向 你 所 标记 的 commit 对 象 的 SHA-1 值 。 同 时 需要 注意 的 是 它 并 不 是 必须 要 指向 
一 个 commit 对 象 ， 你 可 以 标记 任何 Git 对 象 。 例 如 ,在 Git 的 源 代 码 里 ， 管 理 者 添加 了 一 个 GPG A9] (这 
一 个 blob 对 象 ) 对 它 做 了 一 个 标签 。 你 就 可 以 运行 : 










































































pu 


$ git cat-file blob junio-gpg-pub 











来 查看 Git 源 代码 里 的 公 钥 . Linux kernel 也 有 一 个 不 是 指向 commit 对 象 的 tag 一 一 第 一 个 tag X 
在 导入 源 代码 的 时 候 创建 的 ， 它 指向 初始 tree (initial tree， 译 者 注 ) 。 
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9.3.3 


你 将 会 看 到 的 第 
然后 推送 代码 过 去 ，Git 会 把 你 最 后 一 次 失 
例如 ， 你 可 以 添加 一 个 叫做 origin 的 remote 然后 把 你 的 master 分 支 推 送 上 去 : 








Remotes 





JL] 




















种 reference 是 remote reference (远程 引用 ， 译 者 注 ) 







































































$ git remote add origin git@github.com:schacon/simplegit-progit.git 


$ git push origin master 


Counting objects: 


11, done. 


Compressing objects: 100% (5/5), done. 

Writing objects: 100% (7/7), 716 bytes, done. 
Total 7 (delta 2), reused 4 (delta 1) 

To git@github.com:schacon/simplegit-progit.git 


allbef0..ca82a6d master -> master 


然后 





看 refs/remotes/or 












































和 服务 器 的 通信 。 





igin/master ix^ 348 


$ cat .git/refs/remotes/origin/master 


ca82a6dff817ec66f44342007202690293763949 


Remote 应 

















和 分 文 主要 





























务 器 上 最 后 状态 的 一 种 书签 。 























9 .4 


我 们 再 来 看 


及 一 个 


Packfiles 



































tag: 


$ find .git/objects -type f 
.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2 
.git/objects/la/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3 
.git/objects/1lf/TaTaA72abf3dd9643fd615f6da379c4acb3e3a # test.txt v2 
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3 
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt vl 
.git/objects/95/85191f37f7b0fb9444f35aO9bf50delOlbeadc2 # tag 
.git/objects/ca/c0cab538b970a37eale769cbbde608743bc96d # commit 2 
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # ‘test content’ 
.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1 
.git/objects/fa/49b077972391ad58037050f2a75f£74e3671e92 # new. txt 
.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3bl5f3d # commit 1 





























下 test Git CE ° 


zlib 压缩 文件 内 容 ， 
你 会 添加 一 些 大 文 伯 
































Ay 





没有 





大 














此 这 些 文件 








太 多 空间 ， 所 有 
































E. 你 就 会 发 现 origin remote 
































refs/remotes 


9.4 节 Packfiles 


。 如 果 你 添加 了 一 个 remote 
E 送 到 这 个 remote 的 每 个 分 支 的 值 都 记录 在 














录 下 。 








的 master 分 支 就 是 你 最 后 一 次 

















区 别 在 于 他 们 是 不 能 被 check out 的 。Git 把 他 们 当 作 是 标记 这 些 了 这 些 分 支 在 服 








目前 为 止 ， 有 11 个 对 象 —— 4 个 blob, 3 个 tree, 3 个 commit 以 

















文件 加 起 来 总 共 仅 





jT 925 字 节 。 



































F 以 演示 Git 的 

















这 个 源 代码 文件 大 小 约 为 12K: 


个 很 有 意思 的 功能 。 将 你 之 前 








到 过 的 Grit JE 














1A] repo.rb X 
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$ curl http://github.com/mojombo/grit/raw/master/lib/grit/repo.rb > repo.rb 
$ git add repo.rb 
$ git commit -m ‘added repo.rb' 
[master 484a592] added repo.rb 
3 files changed, 459 insertions(+), 2 deletions(-) 
delete mode 100644 bak/test.txt 
create mode 100644 repo.rb 
rewrite test.txt (100%) 























如 果 查 看 一 下 生成 的 tree， 可 以 看 到 repo.rb 文件 的 blob 对 象 的 SHA-1 fH: 





















































$ git cat-file -p master {tree} 


100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt 
100644 blob 9bcldc421dcd51b4ac296e3e5b6e2a99cf44391e repo.rb 
100644 blob e3f094f522629ae358806b17daf78246c2'7c007b test.txt 

















然后 可 以 用 eit cat-file 命令 查看 这 个 对 象 有 多 大 : 



































$ git cat-file -s 9bcldc421dcd51b4ac296e3e5b6e2a99cf44391e 
12898 





稍微 修改 一 下 些 文件 ， 看 会 发 生 些 什么 : 





$ echo '# testing' >> repo.rb 
$ git commit -am 'modified repo a bit' 
[master ablafef] modified repo a bit 


1 files changed, 1 insertions(+), 0 deletions(-) 














查看 这 个 commit 生成 的 tree， 可 以 看 到 一 些 有 趣 的 东西 : 






































$ git cat-file -p master^(tree) 


100644 blob fa49b077972391ad58037050f2a'75f74e3671e92 new. txt 
100644 blob 05408d195263d853f09dca71d55116663690c27c repo.rb 
100644 blob e3f094f522629ae358806b17daf78246c27c007b THEW el 
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4 





TF 








最 后 加 入 ] 





blob 对 象 与 之 前 的 已 经 不 同 了 。 这 说 明 虽 然 只 是 往 一 个 400 行 的 文人 
新 的 对 象 来 保存 新 的 文件 内 容 : 
































$ git cat-file -s 05408d195263d853f09dca71d55116663690c27c 
12908 


212 


4 


TAR, Git 却 
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9.4 节 Packfiles 


REA 








个 对 象 的 差 


的 格式 叫 松散 对 象 (Loose object) 格式 。Git 







































































你 的 磁盘 上 有 了 两 个 几乎 完全 相同 的 12K 的 对 象 。 如 果 Git 只 完整 保存 其 中 一 个 ， 
RAR, BRETT 

事实 上 Git 可 以 那样 做 。Git 往 磁 盘 保存 对 象 时 默认 使 
时 不 时 地 将 这 些 对 象 打包 至 一 个 叫 packfile 的 二 进 制 文件 以 节省 空间 并 提高 效率 。 当 仓 
象 ， 或 是 手工 调用 sit ge 命令 ， 或 推送 至 远程 服务 器 时 ，Git 都 会 这 样 做 。 手 工 调用 
库 中 对 象 打包 并 看 会 发 生 些 什么 : 
$ git gc 


17, done. 


Delta compression using 2 threads. 


Counting objects: 


Compressing objects: 100% (13/13), done. 
Writing objects: 100% (17/17), done. 
Total 17 (delta 1), reused 10 (delta 0) 














查看 


下 objects 























$ find .git/objects -type f 








.git/objects/71/08f7ecb345ee9d0084193f147cdad4d2998293 
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 


.git/objects/info/packs 


.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45 . idx 
.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45. pack 




















































































































目录 ， 会 发 现 大 部 分 对 象 都 不 在 了 ， 与 此 同时 出 现 了 两 个 新 文 伯 





T 

















有 太 多 的 松散 对 


命令 让 Git 将 





T 
| 









































































































































































































































仍 保留 着 的 几 个 对 象 是 未 被 任何 commit 引用 的 blob 一 一 在 此 例 中 是 你 之 前 创建 的 "what is up, 
doc?" 和 "test content" 这 两 个 示例 blob。 你 从 没 将 他 们 添加 至 任何 commit， 所 以 Git 认为 它们 是 
“悬空 ” 的 ， 不 会 将 它们 打包 进 packfile 。 

剩 下 的 文件 是 新 创建 的 packfile 以 及 一 个 索引 。packfile 文件 包含 了 刚才 从 文件 系统 中 移 除 的 所 有 对 
象 。 索 引文 件 包含 了 packfile 的 偏 移 信息 ， 这 样 就 可 以 快速 定位 任意 一 个 指定 对 象 。 有 意思 的 是 运行 gc fü 
令 前 磁盘 上 的 对 象 大 小 约 为 12K ， 而 这 个 新 生成 的 packfile 仅 为 6K bh e MITAR RRD T — ER 2 
使 用 空间 。 

Git 是 如 何 做 到 这 点 的 ? Git 打包 对 象 时 ， 会 查找 命名 及 尺寸 相近 的 文件 ， 并 只 保存 文件 不 同 版 本 之 间 的 差 
异 内 容 。 可 以 查看 一 下 packfile ， 观 察 它 是 如 何 节 省 空间 的 。git verify-pack 命令 用 于 显示 已 打包 的 内 容 : 





























$ git verify-pack -v \ 














.git/objects/pack/pack-7al6e4488ae40c7d2bc56ea2bd43e25212a66c45. idx 


0155eb4229851634a0f03eb265b69f5a2d56f341 
05408d195263d853£09dca71d55116663690c27c 
09f01cea547666f£58d6a84d809583841a7c6f0130 
1a410efbd13591db07496601ebc7a059dd55cfe9 
lfTaTa4T72abf3dd9643fd615f6da379c4acb3e3a 
3c4e9cd7894d884d8d89c1073707c3585e41b0e614 
484a59275031909e19aadb7c92262719cfcdf19a 
83baae61804e65cc73a7201a7252750c76066a30 
9585191f37f7b0fb9444f35a9bf50del91beadc2 
9bcldc4A21dcd51b4ac296e3e5b6e2a99cf44391e 
05408d195263d853f09dca714d55116663690c27c 


tree 71 76 5400 
blob 12908 3478 874 
tree 106 107 5086 
commit 225 151 322 
blob 10 19 5381 
tree 101 105 5211 
commit 226 153 169 
blob 10 19 5362 

tag 136 127 5476 
blob 7 18 5193 1 


\ 


ablafef80fac8e34258ff4lfclb867c702daa24b commit 232 157 12 
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iss 


cac0cab538b970a37eale769cbbde608743bc96d 
d8329fc1cc938780ffdd9f94e0d364e0ea74f579 
e3f094f522629ae358806b17daf78246c27c007b 
f8f51d7d8a1760462eca26eebafde32087499533 
fa49b077972391ad58037050f2a75f74e3671e92 
fdf4fc3344e67ab068f836878b6c4951e3b15f3d 


chain length - 1: 1 object 


pack-7al6e4488ae40c7d2bc56ea2bd43e25212a66c45. pack: 





















































commit 226 154 473 


tree 36 46 5316 
blob 1486 734 4352 
tree 106 107 749 
blob 9 18 856 


commit 177 122 627 


ok 
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如 果 你 还 记得 的 话 ， 9bcld 这 个 blob 是 repo.rb 文件 的 第 一 个 KÆ, ^^ blob 引用 了 05408 这 个 blob, 
即 该 文件 的 第 二 个 版 本 。 命 令 输出 ee SM 12K 空间 ， 而 
9bcld 仅 为 7 字 节 。 非 常 有 趣 的 是 第 二 个 版 本 才 是 完整 保存 文件 内 容 的 对 象 ， 而 第 一 个 版 本 是 以 差异 方式 保存 
的 一 一 这 是 因为 大 部 分 情况 下 需要 快速 访问 文件 的 最 新 版 本 。 

最 妙 的 是 可 以 随时 进行 重新 打包 。Git 上 自动 定期 对 仓库 进行 重新 打包 以 节省 空间 。 当 然 也 可 以 手工 运行 git 
gc 命令 来 这 么 做 。 

9.5 The Refspec 

这 本 书 读 到 这 里 ， 你 已 经 使 用 过 一 些 简单 的 远程 分 支 到 本 地 引用 的 映射 方式 了 ， 这 种 映射 可 以 更 为 复杂 。 
假设 你 像 这 样 添加 了 一 项 远程 仓库 : 
$ git remote add origin git@github.com:schacon/simplegit-progit.git 

它 在 你 的 .git/config 文件 中 添加 了 一 节 ， 指 定 了 远程 的 名 称 (origin) ,远程 仓库 的 URL 地 址 ， 和 用 于 获取 操 


作 的 Refspec: 


[remote "origin"] 


url = gitogithub.com:schacon/simplegit-progit.git 
fetch = trefs/heads/*:refs/remotes/origin/* 


Refspec 的 格式 是 一 个 可 选 的 + 号 ， 接 着 是 <src>:<dst> 的 格式 ， 



























































































































































这 里 <src> utim LAYS 





用 格式 ， 











<dst> 
























































































































































是 将 要 记录 在 本 地 的 引用 格式 。 可 选 的 + 号 告诉 Git 在 即使 不 能 快速 演进 的 情况 下 ， 也 去 强制 更 新 它 。 

人 缺 省 情况 下 refspec 会 被 git remote add 命令 所 动 生成 ， Git 会 获取 远 om E refs/heads/ 下 面 的 所 有 3 
] ， 并 将 它 写 入 到 本 地 的 refs/remotes/origin/. 所 以 ， 如 果 远 端 上 有 一 个 master 分 文 ， 你 在 本 地 可 以 通过 下 画 
这 种 方式 来 访问 它 的 历史 记录 : 

git log origin/master 

git log remotes/origin/master 

git log refs/remotes/origin/master 

它们 全 是 等 价 的 ， 因 为 Git 把 它们 都 扩展 成 refs/remotes/origin/master. 

如 果 你 想 让 Git 每 次 只 拉 取 远程 的 master 分 文 ， 而 不 是 远程 的 所 有 分 文 ， 你 可 以 把 fetch 这 一 行 修改 成 














li 
TE 


ud 
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fetch = *refs/heads/master:refs/remotes/origin/master 





这 是 sit fetch 操作 对 这 个 远 端的 缺 
如 可 以 这 样 拉 取 远程 的 master 分 支 到 本 地 的 origin/mymaster 分 支 : 


个 refspec. 


ZI 




















refspec {Ë 


9.5% The Refspec 


























。 而 如 














$ git fetch origin master:refs/remotes/origin/mymaster 


你 也 可 以 在 命令 行 上 指定 多 个 refspec. 





Bax 





$ git fetch origin master:refs/remotes/origin/mymaster \ 


topic:refs/remotes/origin/topic 


From git@github.com:schacon/simplegit 















































































































































:你 只 想 做 一 次 该 操作 ， 也 可 以 在 命令 行 


fF 可 以 一 次 获取 远程 的 多 个 分 支 : 


上 指定 这 






































用 而 拉 取 操作 被 拒绝 。 你 可 以 在 refspec 之 前 











权时 都 获取 master 和 experiment 分 支 ， 就 添加 


! [rejected] master -» origin/mymaster (non fast forward) 
* [new branch] topic -> origin/topic 
在 这 个 例子 中 ， master. 分 支 因 为 不 是 一 个 可 以 快速 演进 的 引 
E. E 二 = hna — o 
使 用 一 个 + 号 来 重 载 这 种 行为 。 
你 也 可 以 在 配置 文件 中 指定 多 个 refspec. 如 你 想 在 每 次 区 有 
A 
N47: 
[remote "origin" | 
url = git@github.com:schacon/simplegit-progit.git 
fetch = *refs/heads/master:refs/remotes/origin/master 
fetch = *refs/heads/experiment:refs/remotes/origin/experiment 
=i ES Sb fae "ux Ate yop Pe eb RB 人 十 
但 是 这 里 不 能 使 用 部 分 通配符 ， 像 这 样 就 是 不 合法 的 : 


fetch = *refs/heads/qa* 














:refs/remotes/origin/qa* 




















但 无 论 如 何 ， 作 


EF 可 以 











sn 
3 RB 45 4x 














间 来 达到 这 个 目 


的 。 如 你 有 






































master 分 支 和 QA 











[remote "origin"] 
url - 
fetch 


fetch 














如 果 你 的 工作 流 很 复杂 ， 有 QA 组 
程 分 文 上 协作 ， 你 可 以 采用 








的 所 


























推 






































这 ff 








H 


有 分 文 ， 你 可 以 使 

















送 的 分 支 、 开 发 
方式 为 他 们 创建 各 





这 样 的 配置 段落 : 























git@github.com:schacon/simplegit-progit.git 
+refs/heads/master :refs/remotes/origin/master 


*refs/heads/qa/* :refs/remotes/origin/qa/* 


























TH 
cr 
a 























ISHII ` AIS 
空间 。 


个 QA 








， 他 们 推送 一 系列 分 支 ， 你 想 每 次 获取 























集成 人 





人 员 推 送 的 分 支 ， 
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9.5.1 推送 Refspec 

采用 命名 空间 的 方式 确实 很 棒 ， 但 QA 组 成 员 第 1 次 
可 以 使 用 refspec 来 推送 。 

如 果 QA 组 成 员 想 把 他 们 




















$ git push origin master:refs/heads/qa/master 














pi 





Id 


果 他 们 想 


让 Git 每 次 运 





[remote "origin"] 


url - gi 


fetch - 


togithub.com:schacon/simplegit-progit.git 
+refs/heads/*:refs/remotes/origin/* 


push = refs/heads/master:refs/heads/qa/master 


L 


这 样 




















9.5.2 删除 引用 





你 也 可 以 使 用 


$ git push orig 


因为 refsp 


是 如 何 将 他 们 的 分 支 失 








git push origin 时 都 这 样 























就 会 让 git push origin 缺 省 就 把 本 地 的 master ^y xc 18 

















动 推送 ， 他 们 可 以 在 配置 文件 









































refspec 来 删除 远程 的 引用 ， 

















in :topic 





ec 的 格式 是 <src>i<dst>, 通过 把 





也 就 是 删除 它 。 


9.6 传输 协议 





Git 可 以 以 


能 传输 协议 。 这 
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EXE l| qa/ 空间 











而 的 
































的 master 分 支 推送 到 远程 的 aa/master 分 支 上 ， 可 以 这 样 运行 : 
































添加 push 值 : 


E 送 到 远程 的 qa/master 分 支 上 。 
































种 主要 的 方式 跨越 两 个 仓库 传输 数 
1 带 你 快速 浏览 这 





























oo 


m 

































































9.6.1 "WX 

Git d&THTTPZ. Efe 8808 PR AML, ix 
过 程 仅仅 是 一 系列 GET 请 求 ， 客 
fetch 的 过 程 : 





E 


$ git clone http://github.com/schacon/simplegit-progit.git 


它 做 的 第 1 伯 





解释 了 为 什么 在 服务 端 要 想 使 
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事情 就 是 获取 info/refs 文 伯 

















psu 


ES 











用 HTTP 传 输 ， 必 须要 开 




















基于 H 






































ZR 





<src> 部 分 留 空 的 方式 ， 这 个 意思 是 是 把 远程 


TTP 协 议 之 上 ， 和 file://，ssh://， 和 git:// SET 
种 主要 的 协议 操作 过 程 。 




















因为 它 在 服务 端 不 需要 有 针对 Git 特有 的 代码 。j 
户 端 可 以 假定 服务 端的 Git 仓 库 中 的 布 








局 。 让 我 们 以 simplegit 库 来 看 





的 topic 分 支 


变 

















文 个 获取 
== 











http- 














是 在 服务 端 运行 了 update-server-info 所 生成 的 ， 这 也 


post-receive 钩子 
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=> GET info/refs 
ca82a6dff817ec66£44342007202690a93763949 refs/heads/master 





T 
































现在 你 有 一 个 远 端 引 用 和 SHA 值 的 列 寻 
出 到 工作 目录 : 





。 下 一 步 是 寻找 HEAD 引 用 ， 这 样 你 就 知道 了 在 完成 后 ， 什 么 应 该 被 检 

























































































=> GET HEAD 


ref: refs/heads/master 























这 说 明 在 完成 获取 后 ， 需 要 检 出 master 分 支 。 这 时 ,已 经 可 以 开始 漫游 操作 了 。 因 为 你 的 起 点 是 在 into/ 
refs 文件 中 所 提 到 的 ca82a6 commit 对象 ， 你 的 开始 操作 就 是 获取 它 : 





















































=> GET objects/ca/82a6dff817ec66£44342007202690a93763949 
(179 bytes of binary data) 

















H 





然后 你 取 回 了 这 个 对 象 一 这 在 服务 端 是 一 个 松散 格式 的 对 象 ， 你 使 用 的 是 静态 的 HTTP GET 请 求 获 取 的 。 
可 以 使 用 zlib 解压 缩 它 ， 去 除 其 头 部 ， 查 看 它 的 commit AF: 













































































$ git cat-file -p ca82a6dff817ec66f44342007202690a93763949 
tree cfda3bf379e4f8dba8717dee5b5aab78aef'7f4daf 

parent 085bb3bcb608ele8451d4b2432f8ecbe6306e7e7 

author Scott Chacon <schacon@gmail.com> 1205815931 -0700 
committer Scott Chacon <schacon@gmail.com> 1240030591 -0700 


changed the version number 
































这 样 ， 就 得 到 了 两 个 需要 进一步 获取 的 对 象 一 cfda3b 是 这 个 commit 对 象 所 对 应 的 tree 对 象 ， 和 085bb3 
是 它 的 父 对 象 ; 











=> GET objects/08/5bb3bcb608ele8451d4b2432f8ecbe6306e7e7 
(179 bytes of data) 














这 样 就 取得 了 这 它 的 下 一 步 commit 对 象 ， 再 抓 取 tree WR: 








=> GET objects/cf/da3bf379e4f8dba8717dee55aab78aef7f4daf 
(404 - Not Found) 














Gi 























Oops - 看 起 来 这 个 tree 对 象 在 服务 端 并 不 以 松散 格式 对 象 存在 ， 所 以 得 到 了 404 响 应 ， 代 表 在 HTTP 服 务 端 
没有 找到 该 对 象 。 这 有 好 几 个 原因 一 这 个 对 象 可 能 在 替代 仓库 里 面 ， 或 者 在 打包 文件 里 面 ， Git 会 首先 检 
查 任何 列 出 的 替代 仓库 : 



































T 
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下 


=> GET objects/info/http-alternates 


(empty file) 









































如 果 这 返回 了 几 个 替代 仓库 列表 ， 
SORT E E EE «AW. Tex 
文件 中 。 要 检查 服务 端 有 哪些 打包 格式 文件 





















































=> GET objects/info/packs 


P pack-816a9b2334da9953e530f27bcac22082a9f5b835. pack 

















这 里 服务 端 
在 服务 端 
T: 




















=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.idx 


ASH ex 











(4k of binary data) 


ria ST OE, Br 
F 时 也 很 有 用 ， 


RS (是 的 ， 它 也 是 被 update-server-info 所 生成 




















现在 你 有 了 这 个 打包 文 
有 对 象 的 SHA 值 ， 








所 包含 的 所 


=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack 


牛 的 索引 ， 

















(13k of binary data) 
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F 一 这 是 一 种 在 





松散 格式 对 象 和 文 借 
文 个 例子 中 没有 替代 仓库 。 所 以 你 所 需 要 | 
， 你 需 要 获取 objects/info/packs 文件 


































































































IT 















































b4 





是 你 可 以 先 检查 它 的 索引 文件 以 确 i 
今 查 你 所 需要 的 对 象 空间 是 在 哪 一 个 打包 文 伯 











以 你 要 的 对 象 显 多 
因为 这 样 就 













































































ay 



































H 





出 了 这 个 打包 文 伯 











IH 


你 要 的 对 象 是 否 在 里 下 





你 可 以 有 















































和 该 对 象 存在 于 


tree WR, ae 











要 单 地 获取 整个 打包 文件 : 

















F 




















mor 它们 全 部 都 在 这 个 你 已 经 下 载 到 的 































































































现在 你 也 有 了 这 个 
文件 里 面 ， 所 以 你 不 用 继续 向 服务 端 请 求 更 
向 master 分 支 ， Git | 作 
整个 过 程 看 起 来 就 像 这 样 








$ git clone http://github.com/schacon/simplegit-progit.git 
Initialized empty Git repository in /private/tmp/simplegit-progit/.git/ 











got ca82a6dff817ec66f44342007202690a93763949 
walk ca82a6dff817ec66f44342007202690a93763949 
got 085bb3bcb608ele8451d4b2432f8ecbe6306e7e7 


Getting alternates list for http://github.com/schacon/simplegit-progit.git 
Getting pack list for http://github.com/schacon/simplegit-progit.git 
Getting index for pack 816a9b2334da9953e530f27bcac22082a9f5b835 
Getting pack 816a9b2334da9953e530f27bcac22082a9f5b835 

which contains cfda3bf379e4f8dba8717dee55aab78aef7f4daf 


walk 085bb3bcb608ele8451d4b2432f8ecbe6306e7e7 
walk allbef06a3f659402fe7563abf99ad00de2209e6 
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9.6.2 智能 协议 












































这 个 HTTP 方 法 是 很 简单 但 效率 不 是 很 高 。 使 用 智能 协议 是 传送 数据 的 更 常用 的 方法 。 这 些 协议 在 远 端 都 有 
Git 知 能 型 进程 在 服务 一 它 可 以 读 出 本 地 数据 并 计算 出 客户 端 所 需要 的 ， 并 生成 合适 的 数据 给 它 ， 这 有 两 类 
传输 数据 的 进程 : 一 对 用 于 上 传 数据 和 一 对 用 于 下 载 。 






































RE 


























y 




















TH 










































































































































































































































































上 传 数据 

为 了 上 传 数据 至 远 端 ， Git 使 用 Send-pack 和 receive-pack 进程 9 这 个 send-pack 进程 运行 在 客户 端 E 它 
连接 至 远 端 运行 的 receive-pack 进程 。 

举例 来 说 ， 你 在 你 的 项 目 上 运行 了 git push origin master, origin 被 定义 为 一 个 使 用 SSH 协 议 的 URL 
Git 会 使 用 send-pack 进程 ， 它 会 启动 一 个 基于 SSH 的 连接 到 服务 器 。 它 党 试 像 这 样 透 过 SSH 在 服务 端 运行 命 
A^ 
S 


$ ssh -x git@github.com "git-receive-pack 'schacon/simplegit-progit.git'" 
005bca82a6df£817ec66£4437202690a93763949 refs/heads/master report-status delete-refs 
003e085bb3bcb608e1e84b2432f8ecbe6306e7e7 refs/heads/topic 















































0000 
这 里 的 git-receive-pack 命令 会 立即 对 它 所 拥有 的 每 个 引 ju — íT z T£yx 4 (514 t| 只 有 master 2 x 







































































和 它 的 SHA 值 。 这 里 第 1 行 也 包含 了 服务 端的 能 力 列表 (这 里 是 report-status 和 delete-refs) 。 
每 一 行 以 4 字 节 的 十 六 进 制 开始 ， 用 于 指定 整 行 的 长 度 。 你 看 到 第 1 行 以 005b 开 始 ， 这 在 十 六 进 制 中 表示 91 ， 
意味 着 第 1 行 有 91 字 市 长 。 行 以 003e 起 始 ， 表 示 有 62 字 节 长 ， 所 以 需要 读 剩 下 的 62 字 节 。 再 行 是 0000 
台 ， 表 示 服 务 器 已 完成 了 引用 列表 过 程 。 
现在 它 知道 了 服务 端的 状态 ， 你 的 send-pack 进程 会 判断 哪些 commit 是 它 所 拥有 但 服务 端 没 有 的 。 针 对 
个 引用 ， 这 次 推送 都 会 告诉 对 端的 receive-pack 这 个 信息 。 举 例 说 ， 如 果 你 在 更 新 master 分 文 ， 并 且 增 加 


experiment 分 支 ， 这 个 send-pack 将 会 是 像 这 样 : 
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0085ca82a6dff817ec66f44342007202690a93763949  15027957951b64cf874c3557a0f3547bd83b3ff6 refs/heads/master report-status 
00670000000000000000000000000000000000000000 cdfdb42577e2506715f8cfeacdbabc092bf63e8d refs/heads/experiment 
0000 


























这 里 的 全 “0 ”的 SHA-1 值 表示 之 前 没有 过 这 个 对 象 一 因为 你 是 在 添加 新 的 experiment 引用 。 如 果 你 在 删 
余 一 个 引用 ， 你 会 看 到 相反 的 : ”就 是 右边 是 全 0 e 

Git 针对 每 个 引用 发 送 这 样 一 行 信息 ， 就 是 旧 的 SHA 值 ， 新 的 SHA 值 ， 和 将 要 更 新 的 引用 的 名 称 。 第 1 行 还 会 
包含 有 客户 端的 能 力 。 下 一 步 ， 客 户 端 会 发 送 一 个 所 有 那些 服务 端 所 没有 的 对 象 的 一 个 打包 文件 。 最 后 ， 服 务 
端 以 成 功 ( 或 者 失败 ) 来 响应 : 









































































































































































































































000Aunpack ok 


下 载 数据 


当 你 在 下 载 数据 时 ， fetch-pack 和 upload-pack 进程 就 起 作 本 可 9 客户 端 启动 fetch-pack 进程 ， 连接 至 远 端 
的 upload-pack 进程 ， 以 协商 后 续 数 据 传 输 过 程 9 
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在 远 端 仓库 有 不 同 的 方式 启动 upload-pack 进程 。 你 可 以 使 用 与 receive-pack 相同 的 透 过 SSH 管 道 的 方式 ， 也 
可 以 通过 Git 后 台 来 启动 这 个 进程 ， 它 默认 监听 在 9418 号 端口 上 。 这 里 fetch-pack 进程 在 连接 后 像 这 样 向 后 
台 发 送 数 据 : 
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003fgit-upload-pack schacon/simplegit-progit.git\0host=myserver .com\0 











它 也 是 以 4 字 下 指定 后 续 字 节 长 度 的 方式 开始 ， 然 后 是 要 运行 的 命令 ， 和 一 个 空 字 节 ， 然 后 是 服务 端的 主机 


















































































































































名 ， 再 跟随 一 个 最 后 的 空 字 节 。 Git 后 台 进 程 会 检查 这 个 命令 是 否 可 以 运行 ， 以 及 那个 仓库 是 否 存在 ， 以 及 
是 否 具 有 公开 权限 。 如 果 所 有 检查 都 通过 了 ， 它 会 局 动 这 个 upload-pack 进程 并 将 客户 端的 请 求 移交 给 它 。 
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A 
如 果 你 透 过 SSH 使 用 获取 功能 ， fetch-pack 会 像 这 样 运行 : 








$ ssh -x git@github.com "git-upload-pack 'schacon/simplegit-progit.git'" 


不 管 哪 种 方式 ， 在 fetch-pack 连接 之 后 ， upload-pack 都 会 以 这 种 形式 返回 : 


4 
o 














0088ca82a6dff817ec66f44342007202690a93763949 HEAD\Omulti_ack thin-pack \ 
side-band side-band-64k ofs-delta shallow no-progress include-tag 

003fca82a6dff817ec66f44342007202690a93763949 refs/heads/master 

003e085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 refs/heads/topic 

0000 






































这 与 receive-pack 响应 很 类 似 ， 但 是 这 里 指 的 能 力 是 不 同 的 。 而 且 它 还 会 指出 HEAD 引 用 ， 让 客户 端 可 以 检查 
是 否 是 一 份 克 隆 。 
在 这 里 ， fetch-pack 进程 检查 它 自己 所 拥有 的 对 象 和 所 有 它 需 要 的 对 象 ， 通 过 发 送 “want” 和 所 需 对 象 
的 SHA 值 ， 发 送 “have” 和 所 有 它 已 拥有 的 对 象 的 SHA 值 。 在 列表 完成 时 ， 再 发 送 “done” 通知 upload-pack 
进程 开始 发 送 所 需 对 象 的 打包 文件 。 这 个 过 程 看 起 来 像 这 样 ; 


















































































































































































































































0054want ca82a6dff817ec66f44342007202690a93763949 ofs-delta 
0032have 085bb3bcb608ele8451d4b2432f8ecbe6306e7e' 
















































































0000 
0009done 

这 是 传输 协议 的 一 个 很 基础 的 例子 ， 在 更 复杂 的 例子 中 ， 客 户 端 可 能 会 文 持 malti ack 或 者 side-band 能 力 ; 
但 是 这 个 例子 中 展示 了 智能 协议 的 基本 交互 过 程 。 
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你 时 不 时 的 需要 进行 一 些 请 理工 作 如 减 小 一 个 仓库 的 大 小 ， 清 理 导 入 的 库 ， 或 是 恢复 丢失 的 数据 。 本 


节 将 描述 这 类 使 用 场景 。 
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9.7.1 维护 






































Git 会 不 定时 地 自动 运行 称 为 "auto gc" 的 命令 。 大 部 分 情况 下 该 命令 什么 都 不 处 理 。 不 过 要 是 存在 世 
多 松散 对 象 (loose object, NE packfile 中 的 对 象 ) 或 packfile, Git 会 进行 调用 sit gc MS ° gc 指 
垃圾 收集 (garbage collect) ， 此 命令 会 做 很 多 工作 : 收集 所 有 松散 对 象 并 将 它们 存 入 packfile， 合 并 这 些 
packfile 进 一 个 大 的 packfile， 然 后 将 不 被 任何 commit 引用 并 且 已 存在 一 段 时 间 ( 数 月 ) 的 对 象 删除 。 


可 以 手工 运行 auto gc MS: 













































































































































































$ git gc --auto 


























了 次 强调 ， 这 个 命令 一 般 什么 都 不 干 。 如 果 有 “7,000 个 左右 的 松散 对 象 或 是 50 个 以 上 的 packfile，Git 
才 会 真正 调用 gc fg 命令 。 可 能 通过 修改 配置 ， 的 gc.auto 和 gc.autopacklimit 来 调整 这 两 个 国 值 ° 
gc 还 会 将 所 有 引用 (references) 入 一 个 单独 文件 。 假 设 仓 库 中 包含 以 下 分 文 和 标签 : 





二 出 














五 






















































































































































































$ find .git/refs -type f 
.git/refs/heads/experiment 
.git/refs/heads/master 
.git/refs/tags/v1.0 
.git/refs/tags/vl.l 






























































这 时 如 果 运 行 sit zc. refs 下 的 所 有 文件 都 会 消失 。Git 会 将 这 些 文件 挪 到 .git/packed-refs 文件 中 去 以 提 
高 效率 ， 该 文件 是 这 个 样子 的 : 





$ cat .git/packed-refs 

# pack-refs with: peeled 
cac0cab538b970a37eale769cbbde608743bc96d refs/heads/experiment 
ablafef80fac8e34258ff4lfclb867c702daa24b refs/heads/master 
cac0cab538b970a37eale769cbbde608743bc96d refs/tags/v1.0 
9585191f37f7b0fb9444f35a9bf50delO9lbeadc2 refs/tags/vl.l 
^1a410efbd13591db07496601ebc7a059dd55cfe9 


























当 更 新 一 个 引用 时 ，Git 不 会 修改 这 个 文件 ， 而 是 在 refs/heads 下 写 入 一 个 新 文件 。 当 查找 一 个 引用 的 SHA 
时 ，Git 首先 在 refs 目录 下 查找 ， 如 果 示 找到 则 到 packed-refs 文件 中 去 查找 。 因 此 如 果 在 refs 目录 下 找 不 
到 一 个 引用 ， 该 引用 可 能 存 到 packed-refs 文件 中 去 了 。 
请 留意 文件 最 后 以 “开头 的 那 一 行 。 这 表示 该 行 上 一 行 的 那个 标签 是 一 个 annotated 标签 ， 而 该 行 正 
个 标签 所 指向 的 commit e 
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TA 















































9.7.2 数据 恢复 


在 使 用 Git 的 过 程 中 ， 有 时 会 不 小 心 丢 失 commit 信息 。 这 一 般 出 现在 以 下 情况 下 : 强制 删除 了 一 个 分 文 
而 后 又 想 重 新 使 用 这 个 分 文 ，hard-reset T — 42) X ATE TET ILARI commit。 如 果 这 真 的 发 生 了 ， 有 
什么 办 法 把 丢失 的 commit 找 回 来 呢 ? 
下 面 的 示例 演示 了 对 test 仓库 主 分 支 进 行 hard-reset 到 一 个 老 版 本 的 commit 的 操作 ， 然 后 恢复 丢失 的 
commit 。 首 先 查 看 一 下 当前 的 仓库 状态 : 
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$ git log --pretty=o 


ablafef80fac8e34258ffAlfclb867c702daa24b 
484a59275031909e19aadb7c92262719cfcdf19a 
la410efbd13591db07496601ebc7a059dd55cfe9 
cac0cab538b970a37eale769cbbde608743bc96d 
fdf4fc3344e67ab068f836878b6c4951e3b15f3d 


接着 将 master IMA 




















$ git reset --hard 1 


$ git log --pretty-o 


n 


neline 

















a410ef 


neline 





modified repo a bit 
added repo.rb 
third commit 

second commit 


first commit 


至 中 间 的 一 个 commit: 


bd13591db07496601ebc7a059dd55cfe9 
HEAD is now at la410ef third commit 


la410efbd13591db07496601ebc7a059dd55cfe9 third commit 
cac0cab538b970a37eale769cbbde608743bc96d second commit 
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit 
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这 样 就 丢弃 了 最 新 的 两 个 comit 一 一 包含 这 两 个 commit 的 分 支 不 存在 了 。 现 在 要 做 的 是 找 出 最 新 的 那 
个 commit 的 SHA， 然 后 添加 一 个 指 它 它 的 分 支 。 关 键 在 于 找 出 最 新 的 commit 的 SHA 一 一 你 不 大 可 能 记 住 
了 这 个 SHA， 是 吧 ? 

通常 最 快捷 的 办 法 是 使 用 git reflog 工具 。 当 你 (在 一 个 仓库 下 ) TLE, Git 会 在 你 每 次 修改 了 HEAD 时 
悄悄 地 将 改动 记录 下 来 。 当 你 提交 或 修改 分 文 时 ，reflog 就 会 更 新 。git update-ref 命令 也 可 以 更 新 reflog, 
这 是 在 本 章 前 面 的 "Git References" omne 该 命令 而 不 是 手工 将 SHA 值 写 入 ref 文件 的 理由 。 任 
可 时 间 运 行 git reflog 命令 可 以 查看 当前 的 状态 : 

git reflog 
1a410ef HEADo(0): la4l0efbd13591db07496601ebc7a059dd55cfe9: updating HEAD 
ablafef HEADo{1}: ablafef80fac8e34258ff41fc1b867c702daa24b: updating HEAD 

可 以 看 到 我 们 签 出 的 两 个 commit ， 但 没有 更 多 的 相关 信息 。 运 行 git log -g 会 输出 reflog 的 正常 日 志 ， 
从 而 显示 更 多 有 用 信息 : 











$ git log -g 


commit la410efbd13591db07496601ebc7a059dd55cfe9 
Reflog: HEAD@{0} (Scott Chacon <schacon@gmail.com>) 


Reflog message: 
Author: 
Date: 


third commit 


updating HEAD 
Scott Chacon <schacon@gmail.com> 


Fri May 22 18:22:37 2009 -0700 


commit ablafef80fac8e34258ff4lfclb867c702daa24b 
Reflog: HEAD@{1} (Scott Chacon <schacon@gmail.com>) 


Reflog message: upda 


Author: 
Date: 


modified repo a 


222 


ting HEAD 


Scott Chacon <schacon@gmail.com> 


Fri May 22 18:15:24 2009 -0700 


bit 
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看 起 来 弄 丢 了 的 commit 是 底下 那个 ， 这 样 在 那个 commit 上 创建 一 个 新 分 支 就 能 把 它 恢复 过 来 。 比 方 说 ， 
可 以 在 那个 commit (ablafef) 上 创建 一 个 名 为 recover-branch 的 分 支 : 



























































$ git branch recover-branch ablafef 

$ git log --pretty=oneline recover-branch 
ablafef80fac8e34258ff41fclb867c702daa24b modified repo a bit 
484a59275031909e19aadb7c92262719cfcdfl9a added repo.rb 
la410efbd13591db07496601ebc7a059dd55cfe9 third commit 
cac0cab538b970a37eale769cbbde608743bc96d second commit 
fdf4fc3344e67ab068f836878b6c4951e3bl15f3d first commit 























BS | 这 这 样 有 了 个 跟 原 JE master 一 样 的 recover-branch 分 支 ， 最 新 的 个 commit 又 找 本 来 了 o 
接着 ， 假 设 引起 commit 丢失 的 原因 并 没有 记录 在 reflog ! 可 以 通过 删除 recover-branch 和 reflog 
来 模拟 这 种 情况 。 这 样 最 新 的 两 个 commit 不 会 被 任何 东西 引用 到 : 





















































































































































$ git branch 一 D recover-branch 


$ rm -Rf .git/logs/ 





























my 





















































因为 reflog 数据 是 保存 在 .git/1ogs/ 目录 下 的 ， 这 样 就 没有 reflog 了 。 现 在 要 怎样 恢复 commit WE? 办 
法 之 一 是 使 用 git fsck 工具 ， 该 工具 会 检查 仓库 的 数据 完整 性 。 如 果 指 定 -tu 选项 ， 该 命令 显示 所 有 未 被 
他 对 象 引用 (指向 ) 的 所 有 对 象 : 

































































$ git fsck --full 

dangling blob d670460b4b4aece5915caf5c68d12f560a9fe3e4 
dangling commit ablafef80fac8e34258ffAlfclb867c702daa24b 
dangling tree aea790b9a58f6cf6f2804eeac9fO0abbe9631e4c9 
dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293 























本 例 中 ， 可 以 从 dangling commit 找到 丢失 了 的 commit。 用 相同 的 方法 就 可 以 恢复 它 ， 即 创建 一 个 指向 该 
SHA 的 分 支 。 

















9.7.3 移 除 对 象 


Git 有 许多 过 人 之 处 ， 不 过 有 一 个 功能 有 时 却 会 带 来 问题 : git clone 会 将 包含 每 一 个 文件 的 所 有 历史 版 本 的 
整个 项 目下 载 下 来 。 如 果 项 目 包 含 的 仅仅 是 源 代码 的 话 这 并 没有 什么 坏处 ， 毕 竟 Git 可 以 非常 高 效 地 压缩 此 
类 数据 。 不 过 如 果 有 人 在 某 个 时 刻 往 项 目 中 添加 了 一 个 非常 大 的 文件 ， 那 们 即便 他 在 后 来 的 提交 中 将 此 文件 删 
掉 了 ， 所 有 的 签 出 都 会 下 载 这 个 大 文件 。 因 为 历史 记录 中 引用 了 这 个 文件 ， 它 会 一 直 存在 着 。 
当 你 将 Subversion 或 Perforce 仓库 转换 导入 至 Git 时 这 会 成 为 一 个 很 严重 的 问题 。 在 此 类 系统 中 ，( 签 
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出 时 ) 不 会 下 载 整个 仓库 历史 ， 所 以 这 种 情形 不 大 会 有 不 良 后 果 。 如 果 你 从 其 他 系统 导入 了 一 个 仓库 ， 或 是 发 
觉 一 个 仓库 的 尺寸 远 超 出 预计 ， 可 以 用 下 面 的 方法 找到 并 移 除 大 (尺寸) 对象 。 

警告 : 此 方法 会 破坏 提交 历史 。 为 了 移 除 对 一 个 大 文件 的 引用 ， 从 最 早 包含 该 引用 的 tree 对 象 开 始 之 后 的 
所 有 commit 对 象 都 会 被 重 写 。 如 果 在 刚 导 入 一 个 仓库 并 在 其 他 人 在 此 基础 上 开始 工作 之 前 这 么 做 ， 那 没有 什 
么 问题 一 一 否则 你 不 得 不 通知 所 有 协作 者 (页 献 者 ) 去 衍 合 你 新 修改 的 commit 。 

为 了 演示 这 点 ， 往 test 仓库 中 加 入 一 个 大 文件 ， 然 后 在 下 次 提交 时 将 它 删 除 ， 接 着 找到 并 将 这 个 文件 从 仓 
































































































































库 中 永久 删除 。 首 先 ， 加 一 个 大 文件 进去 : 
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$ curl http://kernel.org/pub/software/scm/git/git-1.6.3.1.tar.bz2 > git.tbz2 
$ git add git.tbz2 
$ git commit -am ‘added git tarball’ 

[master 6d£7640] added git tarball 

1 files changed, 0 insertions(+), 0 deletions(-) 

create mode 100644 git.tbz2 















































喔 ， 你 并 不 想 往 项 目 中 加 进 一 个 这 么 大 的 tar 包 。 最 后 还 是 去 掉 它 : 


























$ git rm git.tbz2 
rm 'git.tbz2' 
$ git commit -m 'oops - removed large tarball 
[master da3f30d] oops - removed large tarball 

1 files changed, 0 insertions(+), 0 deletions(-) 
delete mode 100644 git.tbz2 



































对 仓库 进行 sc 操作 ， 看 占用 了 空间 : 




















$ git gc 

Counting objects: 21, done. 

Delta compression using 2 threads. 
Compressing objects: 100* (16/16), done. 
Writing objects: 100% (21/21), done. 
Total 21 (delta 3), reused 15 (delta 1) 














可 以 运行 count-objects 以 查看 使 用 了 多 少 空间 : 











$ git count-objects -v 
count: 4 

size: 16 

in-pack: 21 

packs: 1 

size-pack: 2016 
prune-packable: 0 
garbage: 0 






































































































































































































































size-pack 征 以 和 干 字 节 为 单位 表示 的 packfiles 的 大 小 ， 因 此 已 经 使 用 了 2B 。 而 在 这 次 提交 之 前 仅 用 了 
2K 左右 一 一 显然 在 这 次 提交 时 删除 文件 并 没有 真正 将 其 从 历史 记录 中 删除 。 每 当 有 人 复制 这 个 仓库 去 取得 
这 个 小 项 目 时 ， 都 不 得 不 复制 所 有 2MB 数据 ， 而 这 仅仅 因为 你 曾经 不 小 心 加 了 个 大 文件 。 当 我 们 来 解决 这 个 
问题 。 




































































首先 要 找 出 这 个 文件 。 在 本 例 中 ， 你 知道 是 哪个 文件 。 假 设 你 并 不 知道 这 一 点 ， 要 如 何 找 出 哪个 OE) 文 
件 占用 了 这 么 多 的 空间 ? 如 果 运 行 eit sec， 所 有 对 象 会 存 入 一 个 packfile 文件 ， 运 行 男 一 个 底层 命令 eit 
verify-pack 以 识别 出 大 对 象 ， 对 输出 的 第 三 列 信息 即 文件 大 小 进行 排序 ， 还 可 以 将 输出 定向 到 tail fp, A 
为 你 只 关心 排 在 最 后 的 那 几 个 最 大 的 文件 : 
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$ git verify-pack -v .git/objects/pack/pack-3f8c0...bb.idx | sort -k 3 -n | tail -3 
e3f094f522629ae358806b17daf78246c27c007b blob 1486 734 4667 
05408d195263d853f09dca714d55116663690c27c blob 12908 3478 1189 
Ta9eb2fba2b1811321254ac360970F£c169ba2330 blob 2056716 2056872 5401 
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最 底下 那个 就 是 那个 大 文件 : 2MB 。 要 查看 这 到 底 是 哪个 文件 ， 可 以 使 用 第 7 章 中 已 经 简单 使 用 过 的 rev-list 
命令 。 若 给 rev-list MOA --objects 选项 ， 它 会 列 出 所 有 commit SHA 值 ，blob SHA 值 及 相应 的 文件 路 
径 。 可 以 这 样 查看 blob 的 文件 名 : 
















































































$ git rev-list --objects --all | grep 7a9eb2fb 
'1a9eb2fba2b1811321254ac360970fc169ba2330 git.tbz2 
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接 下 来 要 将 该 文件 从 历史 记录 的 所 有 tree 中 移 除 。 很 容易 找 出 哪些 comit 修改 了 这 个 文件 : 























$ git log --pretty-oneline -- git.tbz2 
da3f30d019005479c99eb4c3406225613985aldb oops - removed large tarball 
6df764092f3e7c8f5f94cbe08ee5cf42e92a0289 added git tarball 






































必须 重 写 从 6df76 开始 的 所 有 commit 才能 将 文件 从 Git 历史 中 完全 移 除 。 这 么 做 需要 用 到 第 6 章 中 用 过 的 


filter-branch 命令 





























$ git filter-branch --index-filter \ 

‘git rm --cached --ignore-unmatch git.tbz2' -- 6df7640^.. 
Rewrite 6df764092f3e7c8f5f94cbe08ee5cf42e92a0289 (1/2)rm 'git.tbz2' 
Rewrite da3f304d019005479c99eb4c3406225613985aldb (2/2) 


Ref 'refs/heads/master' was rewritten 





























--index-filter 选项 类 似 于 第 6 章 中 使 用 的 --tree-filter 选项 ， 但 这 里 不 是 传 入 一 个 命令 去 修改 磁盘 上 签 出 的 
文件 ， 而 是 修改 暂 存 区 域 或 索引 。 不 能 用 rm file 命令 来 删除 一 个 特定 文件 ， 而 是 必须 用 mit rm --cached 来 
MRE 一 一 即 从 索引 而 不 是 磁盘 删除 它 。 这 样 做 是 出 于 速度 考虑 iF Git 在 运行 你 的 filter 之 前 
无 需 将 所 有 版 本 签 出 到 磁盘 上 ， 这 个 操作 会 快 得 多 。 也 可 以 用 --tree-filter 来 完成 相同 的 操作 。git rm 的 -- 
ignore-unmatch 选项 指定 当 你 试图 删除 的 内 容 并 不 存在 时 不 显示 错误 。 最 后 ， 因 为 你 清楚 问题 是 从 哪个 commit 

始 的 ， 使 用 filter-branch 重 写 自 6df7640 这 个 commit 开始 的 所 有 历史 记录 “。 不 这 么 做 的 话 会 重 写 所 有 历史 
记录 ， 花 费 不 必要 的 更 多 时 间 。 

现在 历史 记录 中 已 经 不 包含 对 那个 文件 的 引用 了 。 不 过 reflog 以 及 运行 filter-branch 时 Git fE .git/refs/ 
original 添加 的 一 些 refs 中 仍 有 对 它 的 引用 ， 因 此 需要 将 这 些 引 用 删除 并 对 仓库 进行 repack 操作 。 在 进行 
repack 前 需要 将 所 有 对 这 些 commits 的 引用 去 除 : 





























































































































































































































































































































































































































$ rm -Rf .git/refs/original 
$ rm -Rf .git/logs/ 
$ git gc 


Counting objects: 19, done. 
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Delta compression using 2 threads . 
Compressing objects: 100% (14/14), done. 
Writing objects: 100* (19/19), done. 
Total 19 (delta 3), reused 16 (delta 1) 




















$ git count-objects -v 
count: 8 

size: 2040 

in-pack: 19 

packs: 1 

size-pack: 7 
prune-packable: 0 
garbage: 0 








repack 后 仓库 的 大 小 减 小 到 了 7K ， 远 小 于 之 前 的 2MB e M size AB T ASA 
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要 完全 把 这 个 对 象 删除 ， 可 以 运行 git prune expire 命令 。 



















































































现在 你 应 该 对 Git 可 以 作 什么 相当 了 解 了 ， 在 一 定 程度 上 也 知道 了 
plumbing 命令 一 一 这 些 命令 比较 底层 ， 且 比 你 在 本 书 其 他 部 分 学 































































































多 
底层 了 解 Git 的 工作 原理 可 以 帮助 你 更 好 地 理解 为 何 Git 实现 ] 
























































流 写 出 自己 的 工具 和 脚本 。 











的 。 本 章 履 盖 了 许 


EF 对象 还 在 松散 对 象 























!， 其 实 并 没有 消失 ， 不 过 这 没有 关系 ， 重 要 的 是 在 再 进行 推送 或 复制 ， 这 个 对 象 不 会 再 传送 出 去 。 如 果真 的 


























到 的 porcelain 命令 要 来 得 简单 。 从 























Git 作为 一 套 content-addressable 的 文件 系统 ， 是 一 个 非常 强 





Git 是 如 何 实现 
前 的 这 些 功能 
EKITE, T 


























， 也 使 你 能 够 针对 你 的 工作 


T 不 仅仅 只 是 一 个 VCS DEAE 


















































村。 和 硕 望 借助 于 你 新 学 到 的 Git 内 部 原理 的 知识 ， 你 可 以 实现 
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,的 有 趣 的 应 


























以 更 高 级 便 











利 的 方式 使 


